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
