[Pkg-mutt-maintainers] mutt-1.6.2, or neomutt?

[Faidon Liambotis]

Hi Kevin,

On Wed, Aug 03, 2016 at 02:56:20PM -0700, Kevin J. McCarthy wrote:
> It looks like the 1.6.2 uploaded to unstable now includes the 32k-line
> patch of "neomutt".
>
> <snip>

First of all, let me start by expressing my gratitude for your work on
mutt. I've been quietly following your work and I've been very happy and
even excited to see it.

Second, to your point: Debian, like basically every distribution out
there, has been traditionally shipping a heavily modified mutt source
tree for many years. 

Debian has been shipping the sidebar since 2008, the NNTP patch since
2009, compressed folders since 2006, the trash patches since 2007, ifdef
since 2007, the sensible browser patch since 2007 and many, many others.
Some of these (mostly sidebar & NNTP) were part of a separate binary
package, "mutt-patched", coming from the same mutt tarball, but the bulk
of those patches (including compressed folders, trash/purge, ifdef etc.)
have traditionally been part of the "mutt" package. This isn't new.
Separately, mutt-kz has been shipped in Debian as a separate
source/binary package as well.

I'm fairly new to being a mutt maintainer (I started approximately 2-3
months ago), but my understanding is that this has been done
traditionally because mutt upstream has been stagnated and not keen on
merging third-party patches. The whole PATCHES mechanism for listing
third-party patches and the https://dev.mutt.org/trac/wiki/PatchList
patch list was unlike anything else I have seen in my many years in the
FL/OSS ecosystem.

As you can imagine, rebasing all those patches after every mutt release
has been a pain for the various mutt maintainers. Maintaining 3 binary
packages has also been a pretty serious maintenance overhead. The
sidebar patch in particular has been a huge pain, with us switching
between the various incompatible/half-broken versions out there such as
Gentoo's, breaking users' configuration files and shipping incompatible
versions with other distributions (Gentoo, Arch, BSDs etc.).

When Richard made this herculean effort of collecting all of those
different patches (and their forks) from the various distributions into
one project, cleaning them up, making sure they apply one on top of each
other and resolving the conflicts, I was personally excited and made the
effort of replacing our patches with the neomutt patchset. It should be
easy to understand why: between the various distros, he is saving us a
lot of our collective time and helps us ship a better product to our
users.

I thought a lot about this situation before shipping neomutt as mutt. I
did that (after reaching consensus with the rest of the mutt
maintainers) because:

- Shipping heavy patches against mutt is standard practice. Everyone has
  been doing so for years and even upstream mutt encourages this with
  the PATCHES mechanism.

- We are not even shipping a pristine neomutt; we carry quite a few
  patches on top of that already (sensible-browser, timeout-hook etc.),
  so the same arguments against naming this package mutt could be said
  about naming it neomutt even.

- It wasn't clear what we would do with the "mutt" package. Debian users
  have been expecting certain features for almost 10 years now, often
  complaining when we temporarily disable them (e.g. NNTP); removing
  these features and reverting to vanilla upstream would be a regression
  and confuse our users. I'm unsure who exactly would benefit from that.

- Richard has explicitly said that neomutt isn't a permanent fork; he
  makes releases on top of upstream mutt and has commited on doing so.

- Richard has been a responsive, responsible upstream, creating a more
  vibrant community around neomutt than mutt has ever been, so I felt
  confident that any bugs arising from the neomutt patchset would be
  quickly dealt with. For example,
  https://dev.mutt.org/hg/mutt/rev/4f4c258ab95c was reported by yours
  truly during my testing, fixed by Richard within a few hours and
  submitted back to you.

- Finally, I was personally hoping that his neomutt situation is going
  to be temporary. I had seen your work on the "default" branch on
  sidebar & trash and hoped that neomutt will be getting smaller as mutt
  upstream catches up. I read your mutt-dev email that indicated that
  you were thinking of shipping 1.7.0 soon.

I'm honestly glad to read your email. It indicates that you care about
what your downstreams ship and the quality of software end-users are
getting. (correct me if I'm wrong).

To me, the ideal situation would be if mutt upstream started getting
more responsive and started merging in a lot of these patches, even if
they are not in ideal shape yet (release early/release often kind of
thing). This fragmented ecosystem with a vanilla mutt tree with 2-3
commiters and hundreds of out-of-tree patches isn't healthy and it
hasn't been for years.

It sounds like a mutt 1.7.0 + neomutt Debian release would be the
closest we have been to upstream mutt since 2006 or so. Would us
shipping that as soon as it gets released as mutt still make you
unhappy?

I don't think we can un-ship neomutt at this point, or ship a vanilla
mutt -- that would just be a disservice to our users. The package is
shipping with both a changelog.Debian and a NEWS.Debian entry (shown on
package upgrades) that mentions that we're shipping neomutt starting
with 1.6.2. mutt -v is also very clear about where to raise upstream
issues, https://github.com/neomutt/neomutt/issues, even though most
users usually report packages against the Debian package (the Debian bug
tracking system lists 182 bug reports right now, the vast majority of
which are upstream bugs or feature requests).

Our priorities are our users, not our upstreams, but I'm still deeply
saddened when I hear about contributors not being happy with how their
work is being used. How else do you think that we could resolve this
situation in a way that benefits everyone?

Best regards,
Faidon