Hi Oswald, > yes, there is a huge difference for the *users*, because as it stands, > they are in fact faced with a whole forrest of branches which they need > to merge by themselves. from the perspective of the developers it is the > same - an external source of random patches.
Exactly. > chasing behind a quick-moving branch with much lower quality standards is > anything between deeply demotivating and unrealistic - that's why you > would need paid people to accomplish that feat. In one of your emails you mentioned, there are most probably some paid developers. Now you're writing "would need" as if there were none of them right now. I'm not sure what is actually your point. Please don't consider it offensive, but chasing is just your fear in my eyes. If the mutt developers would feel like that (plus demotivated and unrealistic), I would say they have definitely *lost the vital approach* of developing mutt *in themselves*. Which could or could not be true, but from the outside, it seems so. I see development as being about developing (and from time to time releasing as well), not just staying around and being quiet almost all the time. > further, when casual contributors see how easy it is to get their > changes integrated into a sufficiently official branch (which it would > be, because it's likely what distributors would use), their motivation > to polish the changes will be lower, thus further complicating the > "proper" maintainers' job. Don't pretend to be pessimistic. According to trac, it's not true that the motivation will be lower. Those who really care about mutt that much that they create a ticket in trac and prepare a patch are definitely sufficiently motivated to polish it. Don't forget, the developers of the stable branch are always present and could do what they want (i.e. decline the ticket), pretty much like now. What you're doing is publicly stating you don't trust anyone (except the core mutt developers) in anything. This is definitely not a vital approach of project development, but quite the opposite. > that's where the current maintainers will throw in the towel, and the > "open" branch becomes the official mainline. > this may (after a phase of massive instability, numerous data losses and > security bugs, and a hg history *nobody* wants to read) turn out to be > the best thing that happened to the project within a decade, but let's > not kid ourselves about the nature of such a thing: it's a fork. Not sure if you're trying to alleviate this serious problem by inventing new kid-tales or just slept badly. > asking > the current maintainers to endorse it by hosting it on the official > infrastructure is ... bold. Developers and maintainers shall be bold :-) > what you are saying is "mutt is from the last millenium, and that's > where it should stay". Exactly - if I'm not mistaken, this is the attitude of most mutt users and I suppose of most developers and maintainers as well. > that's an understandable attitude for somebody > who merely wants to get rid of a backlog of 3rd party patches, but isn't > exactly a perspective that would motivate anybody to revitalize the > project (it's oxymoronic to start with). I don't see any connection between incorporation of patches from trac on a half-trusted developer basis and the attitude of "mutt is stable, has its own direction - which corresponds with the way MUA was used in the last millenium - and it should stay like that". So I don't quite get the inferred statement about backlog and motivation, on which the oxymoronic feel was built. Kind regards -- Jan Pacner
