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

[Richard Russon]

> 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've made a great effort to bring together patches, tidy code, help out
the distros with integration and support, I've encouraged new people to
contribute, mentored them.  I've fostered a community that want to help
and want the project to succeed.  Also, I've started to spread the
responsibility of managing the project to speed up development and
prevent myself from becoming a bottleneck.

This is exactly what the Mutt devs should be doing but aren't.

> and merge in just the important and relevant patches from mutt

Upstream mutt are still fixing bugs and making changes that we can't
afford to ignore.  NeoMutt is still too small and our knowledge of the
code still too shallow (but learning fast).

> To fork or not to fork?

Are we a fork?

> hopefully modernised?

Besides all the shiny features that we've added, modernisation is a very
important goal.

Damien (dkc) refactored the mailboxes
Pietro (gahr) refactored the hcache

As we learn more about the code we will start cleaning up the codebase,
undoing the neglect of twenty years.

> refactoring means more changes - and probably breaking away from mutt.

So far this hasn't been much of a problem.  Mutt is moving slowly and a
lot of the features are fairly self-contained.

As we get more ambitious and refactor more widely, it'll become hard to
merge upstream mutt's fixes.

By that point we need enough manpower and momentum to continue on our own.

> [libraries] gnulib?  libuv?

Before people get excited, these are not going to happen any time soon.
They're both good ideas, though.

> gnulib

Very portable wrappers around a host of functions.
Replace mutt's wrappers with modern, portable versions.
This would simplify mutt and move a lot of the support burden to gnu.

> libuv

A portable low-level, asynchrous library.
Wow, the difference this could make!
This would reduce mutt to just a simple MUA with the work done by others.

> portability

Of course using these libraries would limit the platforms that we could
support, but probably not by much.

> "Object Orientedness"..

This is where we can start.  We need to perform a deep analysis of all
the structures of mutt and how data is passed between them.  Then figure
out a plan for improving it.

Rich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.neomutt.org/pipermail/neomutt-devel-neomutt.org/attachments/20170127/4a44a493/attachment.sig>