[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-03 13:40:12
Message-ID: 524D73BC.5000201 () redhat ! com
[Download RAW message or body]

Well,

if you don't mind, I would try to make a small intermediate aggregation
of the current topics discussed regarding the purpose of this discussion
(which is solving the declining vitality of the mutt project).

Except for many examples of technical stuff, patches and situations
where the project upstream wasn't able (disregarding the reason, but
especially due to lack of time) to integrate or even accept those
changes, there were points about forking, the difficulty to get commit
rights, encouraging new devs etc.

Let me propose a fairly minor change in the development process. First,
introduce a special branch in mercurial for a "user-developed" version
of mutt. Commit rights for this branch would be given immediately
(without any patch reviews etc.) to anyone who requests them on the dev
mailing list and has created

1) a ticket in trac with a patch (applicable to the current revision of
this special branch)
2) or a patch (applicable to the current revision of this special
branch) to an already existing ticket

The patch wouldn't have to break the build. No other rules would take
place and these aforementioned ones would be the only necessity.

This special branch would be considered like something between unstable
and testing branch in Debian. The need to open ticket in track with
proper description of a problem/enhancement and providing a patch (even
if the patch would be from someone else) should be enough for the one
who wrote the description or the one who provided the patch to be
allowed to commit into this special branch. The ticket would reside
there until the upstream devs would not reject it or incorporate it
(accept the ticket) into the stable release (i.e. main branch).

The unix/linux distributions/versions shall provide both versions of
mutt or only the one from this special branch. More conservative
distributions would focus on the stable releases, but otherwise it would
be recommended to use the one from this special branch. The feel of
responsibility for their patches will lead the patch providers to make
the patches stable enough to become part of most distributions. This
approach of preference of the special branch shall be appropriately
presented on the main project page (http://www.mutt.org/) and on the
track page (http://dev.mutt.org/trac/) as well.

The upstream devs could then (with the current frequency) release stable
builds based on this special branch with some exceptions (e.g. not
accepting some controversial patches - as measured by the overall
dissatisfaction on mutt mailing lists). This way the upstream devs can
see what the mutt community really uses and incorporate (close the
ticket as resolved) or throw away (close the ticket as won't fix) the
stuff. Keep in mind, they could manage even with their current
time-windows (i.e. no more time would be needed to maintain/develop mutt).

I think, this is worth trying because of its bleeding-edge feel while
retaining the mutt stability ("conservatism") and its zero deployment
time (few commands to create the special branch and then few
commands/edits to add a new committer). The proposal is all about
delegation of the decision (about accepting particular patches) to the
distribution packagers or even directly to users by letting them choose
from the two provided variants. This principle shouldn't discourage
committers and should not burden the upstream devs.

Feel free to comment and/or propose any other viable solution

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