[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-11-04 10:22:51
Message-ID: 5277757B.5090302 () redhat ! com
[Download RAW message or body]

Hi Holger,

> try more context. hint: it's a response to what *you* wrote.

Well, it seems we both have no idea if some of mutt devs are paid or
not, so let's move to the next point :).

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

From experience - mutt is a mature product for "power geeks". I suppose
nobody who supplied some patch to track is a beginner and therefore
there is a high probability they would do the same work as just up until
now. They have no reason to lower their effort but quite the opposite
("Wow, I can play more integral role in mutt project, let's do my work
better!").

> and who makes these decisions? you eliminated the maintainers' authority
> over that branch.

Actually I didn't - someone is always a maintainer of the repository
itself. As for the question about making decisions, KISS suggests me to
send an email to mutt-dev list stating that "I'm against that particular
change because of blabla... This discussion will be evaluated exactly in
2 weeks from now.". The repository maintainer then (after the 2 weeks)
gathers the responses and without any further questioning will act
accordingly. In the meantime anything might happen (changes in that
patch, some deep or flat discussion, voting, whatever...).

Just a humble example, but for your imagination. Always remember KISS :).

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

But not the end-users nor packagers :).

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

Well, I just want to provide a choice to end-users. Between
"ultra-stable" and "quick-moving-without-warranty". Currently there is
no such choice.

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

This is a new idea to me - thank you for pointing it out. If you came up
with it yourself, maybe it reflects your inner feelings/attitudes...

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

Well, forking definitely doesn't demand being bold. But claiming the
title does. In the context of our discussion, the boldness would be e.g.
trying to negotiate some sort of a change in the project, not just
copying the current code base and hostile takeover of the title.

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

Are you sure the mutt community acts more or less according to
survey/description from 1998-2000?

As I'm bold, I would say no :) according to my experience from different
places I've worked in and with many different people there.

Regards

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