[neomutt-devel] To fork or not to fork?

[Damien Riegel]

On Fri, Jan 27, 2017 at 10:28:58PM +0100, Guillaume Brogi wrote:
> On Fri, Jan 27, 2017 at 03:45:36AM +0000, Richard Russon wrote:
> > > To fork or not to fork?
> > 
> > That's always been the trickiest question.
> > One that I've been doing my best to avoid answering.
> > 
> > > Do we want to be just an extended mutt with many patches
> > > applied but following [upstream mutt]
> > 
> > No, not really.  I foolishly hoped that supplying patches and being
> > enthusiastic might kickstart development on Mutt.  I was wrong.
> > 
> > > Or shall Neomutt be something of its own
> > 
> > Damned right, it should.
> > 
> 
> I'm pretty sure that answers the question. In the long run, we're going
> to be a fork. But that doesn't mean we have to burn the bridges tonight.

(TL;DR: it's already a fork!)


Of course not, but the feelings I had while interacting with both
communities is that they don't share the same objectives. Mutt has the
"run every where and don't break" philosophy, so commits that intend to
change the code base just to make it more modern or cleaner are viewed
skeptically (they are considered but with a (big) pinch of salt).

But the code is very hard to reason about, and to be honest I originally
started the mailbox refactoring because I could not understand some
stuff in there. I think that a cleaner code base should not be a
nice-to-have, but a must-have, and that might be a point of friction
between the two projects.

Plus, Neomutt has already attracted a few people, and upstream mutt is
mostly a one-man job. So even if neomutt's goal was to contribute back
everything to upstream, it would not be feasible due to the way upstream
is organized/managed.

And maybe the original goal was to be some kind of mutt-next, the
momentum neomutt is gaining makes it more and more a "fork".

-- 
Damien