> I could not sit any non-technical user in front of it and have it make sense to them
So name a bug tracker with equivalent or greater flexibility to Fossil's that non-technical users do understand.
I've only used one bug tracker that's simpler than Fossil's, and that's because it had far fewer user-facing features.
Every other bug tracker I've had to use requires some training once you get past the "submit ticket" form. And a few required training even to successfully fill that out!
> Fossil's lack of any built-in emailing was also lousy.
Email is hard. Seriously hard. RFCs 821 and 822 are only the tip of an enormous iceberg. If Fossil only did the basics, it would fail for a whole lot of real-world use-cases, and it'll only get worse as email servers get tightened down more and more, to combat spam, email fraud, domain hijacking, etc.
I, too, would like Fossil to mail out commit tickets and such, but I'm not sure I want the build time for the binary and the binary size to double just because of all the protocol handlers it would need to do this properly. Keep in mind also that Fossil generally doesn't link out to third-party libraries. There are exceptions, but then, I'm not aware of a widely-available[1] full-stack SMTP library, so it would probably have to reimplement all of it internally.
Now, if you want to talk about adding a simple gateway that would allow it to interface with an external MTA, that would be different. I suspect the only thing wanting there is for someone to get around to writing the code. I don't want it bad enough to do it myself.
> "it's supposed to work that way" instead of "hey, maybe you, the user, are onto something".)
If you propose something that goes against the philosophy of Fossil, then of course the idea will be rejected. We keep seeing git users ask about various sorts of history rewriting features for example. Not gonna happen. No sense having a philosophy if a user request can change it.
If you're talking about a Fossil behavior that isn't tied to its philosophy, but it just works the way it does for some reason, logic and persuasion are a lot less effective than working code. The Fossil core developers accept patches.
----------
[1] I mean something you can expect to be in all the major package repositories, and in binary form for Windows.
I am happy that Fossil works well for you. I long ago stopped being interested in tweaking my version control system or living with "email is hard, let's move on" and I moved onto other things.
I still think the Fossil value proposition--one file with all your project ephemera--is a good one. It'd be neat if BitMover produce something similar, e.g. maybe not a file, maybe a directory, but same idea, etc.
So name a bug tracker with equivalent or greater flexibility to Fossil's that non-technical users do understand.
I've only used one bug tracker that's simpler than Fossil's, and that's because it had far fewer user-facing features.
Every other bug tracker I've had to use requires some training once you get past the "submit ticket" form. And a few required training even to successfully fill that out!
> Fossil's lack of any built-in emailing was also lousy.
Email is hard. Seriously hard. RFCs 821 and 822 are only the tip of an enormous iceberg. If Fossil only did the basics, it would fail for a whole lot of real-world use-cases, and it'll only get worse as email servers get tightened down more and more, to combat spam, email fraud, domain hijacking, etc.
I, too, would like Fossil to mail out commit tickets and such, but I'm not sure I want the build time for the binary and the binary size to double just because of all the protocol handlers it would need to do this properly. Keep in mind also that Fossil generally doesn't link out to third-party libraries. There are exceptions, but then, I'm not aware of a widely-available[1] full-stack SMTP library, so it would probably have to reimplement all of it internally.
Now, if you want to talk about adding a simple gateway that would allow it to interface with an external MTA, that would be different. I suspect the only thing wanting there is for someone to get around to writing the code. I don't want it bad enough to do it myself.
> "it's supposed to work that way" instead of "hey, maybe you, the user, are onto something".)
If you propose something that goes against the philosophy of Fossil, then of course the idea will be rejected. We keep seeing git users ask about various sorts of history rewriting features for example. Not gonna happen. No sense having a philosophy if a user request can change it.
If you're talking about a Fossil behavior that isn't tied to its philosophy, but it just works the way it does for some reason, logic and persuasion are a lot less effective than working code. The Fossil core developers accept patches.
----------
[1] I mean something you can expect to be in all the major package repositories, and in binary form for Windows.