[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mutt-dev
Subject:    Re: The future of mutt... - intermediate aggregation
From:       Oswald Buddenhagen <ossi () kde ! org>
Date:       2013-10-25 8:02:17
Message-ID: 20131025080217.GA28185 () ugly ! local
[Download RAW message or body]

On Thu, Oct 24, 2013 at 10:33:22AM +0200, jpacner@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).
[prev in list] [next in list] [prev in thread] [next in thread]