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

List:       mutt-dev
Subject:    Re: The future of mutt... - intermediate aggregation
From:       "jpacner () redhat ! com" <jpacner () redhat ! com>
Date:       2013-10-24 8:33:22
Message-ID: 5268DB52.6040708 () redhat ! com
[Download RAW message or body]

Hi Oswald,

>> 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."

> of course it is (*), and that's the whole point. you are asking them to
> concede that they are just in the way

Exactly.

> and to endorse whatever follows.

Not at all - therefore the *open* discussion about "the future of mutt"
- they can fully influence (pretty much like you and me) the conclusions
and results.

> it would be more fair to ask them directly to officially step down and
> hand out mainline commit rights no-strings-attached to almost anyone,
> instead of doing it through the backdoor of a branch.

Please don't make any conspirative theories, we are not sitting in a pub
with glass of beer.

>> 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.

> 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.

>> What you're doing is publicly stating you don't trust anyone (except
>> the core mutt developers) in anything.
>>
> this is entirely true, and judging from experience with my own projects
> it is an entirely reasonable approach.

Yes, but not always. And what we cannot fully agree on is, that this
approach is not convenient for mutt.

> 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.

> 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.

> of course you should, but be careful where you apply the boldness.
> first deliver, then be bold.

That's what my proposal is about - deliver more often according to mutt
users needs.

>>> 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. it's the impression some
> non-contributing loudmouths on the lists create, but it is in no way
> representative. the wish list on trac speaks a very clear language. i
> also don't think the maintainers want mutt to be stale - they just don't
> have the time/motivation to push it forward themselves, and nobody
> they'd trust to take over.

Hm, this means we should do some survey on all mutt mailing lists and
mutt website. Otherwise we can't argue which one is true. Don't forget,
time matters and what most mutt users expected 7 years ago must not be
valid today. I'll try to negotiate exposure of this small, but
long-running survey on the main mutt website and track main site. Notice
the dates (opened and last modified) of mutt requests for enhancement
(wish list) - they speak a very clear language as well.

> this wouldn't quite work if somebody with significantly
> diverging ideas took over. in the end you might get something better
> than what you wanted, but it doesn't match your current integrative/
> conservative focus.

I have quite different experience with "generic distro guys". They are
focused on delivering what the users want and try to adapt to it. They
are all but not interested when upstream splits or whatever - they just
choose what users want/need. If users demand stable version, they
deliver the stable one. If bleeding-edge one, they just deliver it. No
complications, no deep thinking, nothing. Just grab, adapt and deliver.

Look at Debian guys - if the upstream doesn't want to cooperate, they
stay calm and fork it or exchange it for an equivalent piece of software.

Of course, many "distro guys" are also highly interested and/or involved
in upstream development, but at the end, they anyway deliver what users
want.

> the oxymoron here is "conservative revitalization".

Hm, I would rather call it "introducing a vital branch and affirming the
current releases as stable - i.e. meant for conservative users.

> anyway, this thread isn't going anywhere. you have two options:
> - play by the rules of the current maintainers: review patches, show a
>   good understanding of the code base, demonstrate dedication, become a
>   maintainer yourself
> - fork somewhere else, and when you think you succeeded, come back and
>   claim the title. yes, this actually worked with the midnight
>   commander.

You pretty much demands me not being bold :). Hopefully you don't bound
yourself by such senseless constraints.

Kind regards

-- Jan Pacner
[prev in list] [next in list] [prev in thread] [next in thread]