z+mutt+neomutt at m0g.net
Mon Feb 13 01:39:32 CET 2017
On Sun, Feb 12, 2017 at 03:55:48PM -0800, David Champion wrote:
> * On 10 Feb 2017, Guyzmo wrote:
> > […] (please prove me wrong), the mutt project is not interested in
> > merging a fat feature like notmuch […] old school users […]
> […] we'd ignore them except where they pointed out actual flaws or
> points of improvement. I've faced this with a number of my own
> patches. My answer? You can disable it.
Sure, it helps.
But technically speaking, I believe it'd be better for the codebase to
avoid all those ifdefs all over the place, and use sane defaults so what
you don't need, you don't see. Why would it be better? Because ifdefs
are making it harder for static analysis tools, and conditional
compilation cause too many combinations to seriously be able to test
each and every condition. All that at the cost of a few megs in 2016.
> The other case where we sometimes reject essentially worthwhile patches
> is when it doesn't appear that there's someone who will "own" it. That
> was the case with sidebar for a very long time. The code was in bad
> shape, the original author (I don't even remember who it was anymore)
> had moved on, nobody was willing to own it until Richard took care of
> it. It would be a poor choice for us to take code we cannot maintain,
> and can't call on someone to maintain. It is definitely thanks to his
> effort that we merged it.
GG Rich, I did not know that ☺
> I don't use notmuch but I realize that it's very popular. If someone
> had shown it the love in a patch that we could merge, I think we'd have
> been interested. But Karel never said hello.
well, the patch is not in a bad shape, and beyond a few stylistic
changes (like switching from tabs to spaces indent) it should be totally
Thank you for summing up the history side, that's definitely good to
know. One needs to learn history to avoid doing the same mistakes again.
That being said, what matters to me really is the technical side. I
don't really know what's your (and mutt committers) plan and vision.
Even more now, as you've shown me that most of what I think I knew about
upstream mutt is likely to be wrong.
As I've been discovering the code base, I'm having my own opinion of
stuff to priorise to introduce some agility (in an opensource project
way) in future development and make the code's easy to grasp for new
But I'd like to know your position (and the "established community"'s)
position on those topics:
• fat features integration (notmuch, lua scripting, nntp, etc.)
• refactoring, reorganizing and documenting the codebase
• process improvement (how to make contributing faster and easier)
More information about the neomutt-devel