[neomutt-devel] mutt vs neomutt

[Guyzmo]

On Fri, Feb 10, 2017 at 03:12:27AM -0800, David Champion wrote:
[…]
> Sven's response was, let's say, very inspirational.  I wrote a lot of
> words.  I spent a lot of time editing them too, but I think they will be
> tl;dr so they aren't here anymore.

More than inspirational, Sven's response was trollesque to say the
least. It looks like some neomutt contributors have been bitten by
unsuccessful attempts to participate in mutt. I'm not one of them, as I
said in my previous post. So I'd rather leave the trolls and emotions
out of the discussion.

I think the issue at hand is how can we create a synergy between mutt
"established community" and neomutt's bazaar, so we can get the most out
of it.

[…]
> To paraphrase: Neomutt is a fork.  There's no way to think otherwise,
> as I read more of your material and look at events.  I think there's
> acknowledgement of that from within, even embracing.  The activity
> within the group is characteristic of a project that fully intends to
> supplant its predecessor.  I just ask that you own it.  The only way
> Neomutt is "not a fork" is if you have or anticipate a proposal for
> merge-back.  I'd be curious what it is.

My position is that if mutt and neomutt have different goals, they
should follow on the vim vs neovim path, and actually _own_ those
differences.

My understanding is that mutt is likely to stay the good old MUA many
loved and some still loves. Very portable, that can run even on AIX4 or
some other forgotten Unix, but without all the shiny features we can
find in all the many patches gathered all across the intertubes.

Then, how I'd see neomutt being a fork? Try to modernise the codebase,
not being afraid of breaking stuff that has been there for ages:

- consider using external dependencies (like libuv for file and network I/O),
- break compatibility with systems we cannot test on (I'm sorry AIX),
- add unit/regression testing and CI,
- add scripting for enabling second class features,
- reformat, refactor and document the code,
- add features like notmuch integration, nntp and other stuff alike.

Would that mean that neomutt would supplant mutt? I don't think so. Many
user will prefer using mutt because they don't need more features, but
want a software that can still run on that 1997 sparc machine.

> Also, if you make a lot of money with your Paypal donation button and
> you don't know what to do with it, may I suggest refugee resettlement or
> MSF?  You can do that with my share of the proceeds, at least.  Say that
> it's from the Mutt project.

I have no problem with that. In any community project, money has always
been a source of issues. To finance feature development, I like the way
bounty source work (and the opencodemarket idea), which is open fair,
and open to anyone.

> Let us know if there's anything you want to cooperate on.  You know
> where to find us.  Naturally you're still welcome to submit patches as
> usual.

As we're defining a vision of what we, users and contributors of
neomutt, want neomutt to be, it's naturally a great idea to confront
that with what the vision of mutt's "established development community"
is. Depending on how much we agree on, and how much we diverge, we
should be able to define whether neomutt is a fork of mutt, or merely an
extended patchset above mutt.

Once we've defined what that is, establishing a sort of "process" for
collaborating between both will be possible.

Cheers,

-- 
Guyzmo