On Thu, Oct 24, 2013 at 10:33:22AM +0200, jpac...@redhat.com wrote: > >> 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. > >> > > i made no such claim regarding mutt. you should re-read the relevant > > mail. > > Well, could you then please rephrase the following statement you made? > > "...these branches are maintained by the same people, or at least that > those maintaining the stable branch are *paid* to actively cherry-pick > from the unstable branch." > try more context. hint: it's a response to what *you* wrote.
> >> Don't pretend to be pessimistic. According to trac, it's not true that > >> the motivation will be lower. > >> > > i wonder how you can know that? > > unless of course you concluded that it already is zero at this point. > > There are still many people creating new tickets and/or reacting on the > current tickets, which is enough to see that they are motivated. > obviously. i'll point out that we were talking about the motivation to polish patches. so how exactly can you deduce from the trac activity how these people would respond to a relaxed commit policy? > > i've been maintainer of sufficiently many projects to know that this > > is not a universally true statement. a significant percentage of casual > > contributors throws some crappy code at you and expects you to be > > grateful for it, possibly flaming you down when you make no such > > pretenses. > > Of course, but they build only a minority and therefore if the others > don't like their work, why not to revert the commit or rewrite the patch > with prompting the original author that the patch was really bad? In > such a small project as mutt is, this approach is fully feasible. Second > time the contributor makes such a mistake, his access to the > vital-branch will be disabled. KISS rulez. > and who makes these decisions? you eliminated the maintainers' authority over that branch. > > indeed. everybody has their priorities. we tend to become more > > conservative (security-focused) with age. > > Well, I'm not certain about this, because security fixes should be fixed > "immediately" and if you compare the time of security ticket creation > and time of next mutt release, you'll realize, this is just plain wrong > argument. > it should have been obvious from the context that security didn't relate to security bugs in particular, but the general life philosophy. when faced with a lack of resources (time, health, interest, whatever), you naturally try to preserve the status quo. > > actually, i'm talking from first-hand experience with the midnight > > commander project. luckily it is a much less critical tool than a mail > > reader. > > It seems, you don't keep in mind, that my proposal retains the current > stable-release release cycle. What are you afraid of then? I wasn't able > to figure it out even after few days of thinking. > when you make the stable releases irrelevant, there won't be any new ones. that's not *too* far from the current state, but it's a different thing to codify it. > >>> 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. > >> > > i think you are thoroughly mistaken about this. [...] > > [...] Don't forget, time matters and what most mutt users expected 7 > years ago must not be valid today. [...] > that's a tad cynical, huh? "those who are *still* around obviously don't care". > > anyway, this thread isn't going anywhere. you have two options: > > - play by the rules of the current maintainers: [...] > > - fork somewhere else, [...] > > You pretty much demands me not being bold :). > i don't see how forking and then claiming the title would not be bold. it's nothing short of a hostile takeover if the ex-maintainers don't endorse it in the end (in the case of mc, the new maintainership was approved). > Hopefully you don't bound yourself by such senseless constraints. > you should read http://catb.org/~esr/writings/homesteading/homesteading/ for a primer on the (unwritten) rules by which most hackers tick (more or less).
