[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-11-12 10:12:16
Message-ID: 20131112101216.GA7891 () ugly ! local
[Download RAW message or body]

On Mon, Nov 11, 2013 at 03:18:21PM +0100, jpacner@redhat.com wrote:
> Hi Oswald,
> > and who makes *that* call? where do you draw the line? it doesn't appear
> > magically, somebody with the competence and guts (=> authority) has to
> > do it.
> 
> If you're bold enough (devs/committers are :)), you'll do it.
> 
that would make me a new maintainer.
wait, we already were at that point in the discussion ...

> > ... but the simple fact is that there is nobody here
> > who wants the job and is up to it, and no degree of trying to be "more
> > welcoming" will change that.
> 
> It might be or might not be so (just thinking about it is neither
> productive nor helpful - doing something [e.g. trying new paths in case
> of mutt] is the way to go). We have devs primarily for stable releases
> and these minions for unstable releases - KISS.
> 
sounds more like BSD to me - Blue Sky Dreams.

> > what might work is surveying the various forks out there, and if one
> > with a competent and reasonably active+cooperative maintainer is found,
> > offer him the job with no further strings attached. the first part can
> > (and probably must) be done by the wider community, the second by the
> > maintainers.
> 
> Sure - if I understand you correctly, you mean "first part" from the
> time-perspective ...
> 
no, actually, i was referring to the first part of my first sentence in
that paragraph. of course there is a time perspective to it, but that's
not the point.

> ... which seems like a "title" for my proposal about introduction of a
> partly-stable branch.
>
i completely fail to understand what you mean.

> >>> then maybe you should explain what you meant? thinking it through
> >>> properly?
> >>
> >> I tried, but didn't notice anyone from "those who are still around" to
> >> not care. Therefore I was a bit surprised by your view/feeling.
> >>
> > this makes no sense. maybe you again forgot what you said yourself?
> 
> Well, "care" in the sense, they try (actively) not to give permissions
> to those who try to improve/fix mutt.
> 
to remind you, the original context was caring about modern features.

> > further, this here is a community which is 20 years old and cleary
> > didn't have significant "modern influences". so what exactly is your
> > point?
> 
> I'm afraid I can't agree with the conclusion "clearly didn't have
> significant ...".
> 
i'm referring to the core community on this list - the (ex-)maintainers
and occasional contributors. the observable behavior seems very
traditional to me, and entirely consistent with esr's essay.

> >> In mutts trac there are plenty of patches from people who tried the
> >> "more agile" variant [...]
> >>
> > uh, what?
> > i see no evidence of a shift in unpaid foss contribution patterns.
> 
> I'm not sure if it's necessary to see the shift, but it's definitely
> necessary to be aware of the current state/attitude and to act accordingly.
> 
yes. but i'm not sure what one has to do with the other.

> > also, the whole "agile" buzz seems utterly inapplicable to loosely knit
> > online communities. or approached differently, they *already were* agile
> > before the corporate world made it a fad.
> 
> Agile in its original meaning (http://en.wiktionary.org/wiki/agile)
> applies to the behavior of devs of many (I would say more than half)
> mutt-sized projects (especially those being so common like mutt) these days.
> 
the one thing that doesn't fit into this sentence is "these days". ;)

anyway, it is very clear that this discussion is not going anywhere.
some of the maintainers have voiced mildly cautionary opinions which are
consistent with what i said. iirc, there was *no* support for your proposal.

if you want to achieve something, you need to deliver something of use.
either you get cracking yourself and strive to be a maintainer, or try
to reach out to other people who might be accepted as maintainers. in
either case, the usual meritocratic rules that are in place apply.

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