[neomutt-devel] mutt vs neomutt

Guyzmo z+mutt+neomutt at m0g.net
Mon Feb 13 16:49:02 CET 2017

On Sun, Feb 12, 2017 at 04:28:54PM -0800, David Champion wrote:
> * On 10 Feb 2017, Guyzmo wrote: 
> You're currently making a lot of decisions about the code that need to
> involve at least Kevin if not more of the mutt-dev group in order for
> there to be any synergy.  Without that there's no _syn_ to it.

ok, how can we change that?

> 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.

So forks are becoming less and less political, and is just a new
paradigm which is defining how people make opensource nowadays. Does
that mean it's less community-oriented and more self-centered? I guess
it is, but let's be honest here, it's how most people do opensource:
do it for yourself first, then share with the others.

> I hate the politics myself.  […]  Looks like you lose either way once
> your community gets to a certain age.

Yup, keeping a community focused on a tool such as a MUA for as long as
mutt has existed definitely is a challenge beyond what I can imagine,
and I admire the dedication you (and others like you) are having for
this project. I haven't worked on anything that lasted that long!

If I want to move beyond the politics it's because you lived the project
from within for almost 20 years, and I'm just a newcomer who did a bunch
of commits on a fork on top of forks of the project, and I only know
hearsay about the history of the project.

> What bothers me is how your group diverged. […] here's my belief:
> nobody can point to a disagreement that directly caused a fork.  It's
> the result of a lot of hearsay and vague concern and sense of
> hopelessness.

That, and also the fact that there were forks and patches scattered all
across the web, which for some have been discarded by the mutt team,
others never even were offered.

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

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.

> 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!

> […] All those things you list sound very exciting.  Mutt would love to
> have them.  I feel a little punched in the gut that you say our
> relevance or desire is to be the mailer of choice for Solaris 2.5.
> That's not true at all.  I would be happy, personally, to cut off
> older operating systems at some appointed version.  It's a great
> principle for 2.0.

Don't feel that way, I'm actually happy to hear you say that, that means
there's a lot we can do together! You see that's another thing I wrongly
assumed based on hearsay. So I'm happy to hear some clarification on it.

> But to be fair we need to manage that process, not just start applying
> breaking patches willy-nilly.  We need to be answerable to our user
> community, not to our developers' sense of glee at doing cool new
> things.

Of course you can't drop things like that one day to the other. But that
does not mean things should slow down. We could handle that the way
python handled a transition from 2 to 3: Having two separate development
branches happening in parallel.

> 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?



More information about the neomutt-devel mailing list