[neomutt-devel] mutt vs neomutt

[Fabian Groffen]

On 13-02-2017 16:49:02 +0100, Guyzmo wrote:
> > I want to mention politics too.  You said that you just want to code and
> > not deal with politics, but forking is the most political thing an open
> > source project can do.  So you really stepped into it there. :/
> 
> Well, if you think about it, anybody who ever published a patch that has
> not made it into mutt's main code base has done a fork. The only thing
> is that those patches can easily be made available and rebased on the
> current upstream thanks to services like Github.

I'd say, thanks to in the first place Mercurial's patchqueues.  It is an
enabler and huge pro.  I maintain a (too) large patchset for Gentoo that
way without much issues, still keeping all patches separate.  I don't
see it as a fork.

> Add a pinch of hearsay about past issues and sprinkle with
> misunderstandings, and you get the debian "rich" version of mutt, and
> several versions offered with optional patches within ports, brew, AUR
> or emerge. In the end, you get too much of the userbase running a fork
> of the code, not the real one, with little control or oversight on that
> code.

I have to agree here that there seem to be very few distributions who
ship Mutt without any patching.  Gentoo provides the "vanilla" variant,
but only to ease bug reporting to upstream, from the reports I get on
our bugzilla I get the impression it's seldomly used.

> Having a guy like Rich doing the collection of those patches and
> applying them in a way that works without too much breakage was just a
> matter of time, especially with a tool like Github making it easier and
> more "normal" to do just that.

Just in case, I think the work Rich did is simply amazing.  With a lot
of pleasure I saw his enthusiasm and energy poored into the various
jumbo patches that existed for Mutt.

I don't quite see how Github makes things so much easier, but as I
discussed with Rich at some point, it's just the tool that works best
for the person doing the work.  IOW the tool is irrelevant here.

> > I feel like that's been taken, because the momentum you have now will
> > probably do a lot of harm to upstream.  I think some of you believe that
> > too, but don't mind as much as I do, of course.
> 
> I don't think it should!

But it probably does.  Fair question is if it is a bad thing for the
larger picture: the users.  Neomutt has done some quantum leaps for
sure, bringing in features lots of people were waiting for (but downstream
distros shipped for long with Mutt), and moving forward from there -- up
to the point where for me as maintainer at a distro and as a user it all
went a bit too fast to my taste.  Time will stabilise it for sure, but
in the meantime Mutt has spurted into development too, going into a
seemingly slower but more controlled path -- in particular when they
include patches from my patch list.

> > When code can't backport, it's a fork.  When developers aren't talking
> > to each other, it's a fork.  With the changes you have in flight, your
> > "patchset" will be more than half the code unless we do things to
> > preserve compatibility that we weren't involved in deciding.
> 
> Currently neomutt did not cross the point of no-return, there still is a
> clear path from mutt to neomutt. About developers not talking to each
> others, isn't it what we're doing right now?

(Note: I'm not a Mutt developer)
From where I stand (applying patches to Mutt) I see Neomutt deviating
from Mutt more and more.  FWIW, I think Neomutt is pretty close to the
point of no-return.  Applying formatting changes will push it over,
turning porting into manual labour.

My probably non-relevant €0.02

Fabian

-- 
Fabian Groffen
Gentoo on a different level
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://mailman.neomutt.org/pipermail/neomutt-devel-neomutt.org/attachments/20170213/2567013a/attachment.sig>