On Thu, Oct 17, 2013 at 10:29:49AM +0200, jpac...@redhat.com wrote: > On 10/07/2013 10:29 AM, Oswald Buddenhagen wrote: > > mutt already has that anything-goes branch: it's called trac. when > > you make an actual hg branch of it, it will be a fork, and master > > will be abandoned for good. > > Well, it seems each of us uses different definition of "fork" in this > context (personally I stick to the definition from wikipedia > http://en.wikipedia.org/wiki/Fork_(software_development) ). > i'm using the same definition. the choice of this word is very deliberate.
> Anyway, even if you call the open-for-almost-all branch a "fork", I > can't agree with the fact that the trac currently acts like such a > branch - there is a really huge difference between picking all working > patches from track (and applying them to the upstream branch) and just > checking out such already existing branch. > 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. > Moreover why do you think the master will be abandoned for good in case > such branch will be introduced? It somehow doesn't fit well with your > statement, that there are people (possibly *paid*) maintaining the > stable branch - why would they stop maintaining it? Let me apologize, > but I don't see any reason for them to act like that. > 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. 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. 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. asking the current maintainers to endorse it by hosting it on the official infrastructure is ... bold. > >>> that means that anyone who'd want to make major functionality > >>> improvements would have to start with substantial refactoring. > >> > >> Well, then he should be aware of the fact, that this is not mutt's > >> goal if I'm not mistaken. Today one can create a simple MUA in > >> python in about one day satisfying his own needs. [... > ...] So, it would be a bit ill-judged if someone really wanted to make > a huge refactorization or alike of mutt only to prepare it for major > functionality improvements. > what you are saying is "mutt is from the last millenium, and that's where it should stay". 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).
