moin,
a somewhat belated reply, but i just finished cleaning up my mutt-dev
folder:
On Wed, Jul 29, 2020 Derek wrote:
I'll be honest--what I'd really prefer to see is the two projects
merge, where "NeoMutt" would be the place were things were tried,
fleshed out, and refined so that they could be included in Mutt.
let me remind everyone that this is pretty much exactly what neomutt
started out as.
Though I suspect by now development has diverged sufficiently to make
that impractical.
yes, it has. to make a long-term "incubator" branch that aims at
actually improving the code base viable, upstream has to be open to even
drastic cleanups/refactorings (obviously, only when they make technical
sense and are delivered as clean, atomic commits). meanwhile, kevin has
been actively hostile towards changes he didn't deem "minimal enough".
that's a reliable way to make sure the code base is stale, rather than
stable.
On Wed, Jul 29, 2020 Kevin wrote:
You have done an amazing job building the community and development
team for NeoMutt, and I... have not.
yeah, it helps to have no standards whatsoever, at least initially. :-D
but more seriously, you *can* do something, and that is shifting your
priorities from maximizing the time available for your own hacking
towards maximizing the time others can and *want* to spend hacking on
"your" code. in particular:
- give timely and detailed feedback. you're actually good at this.
- *don't* finish up or even rewrite changes yourself. i know it's
tempting (and i do it myself all the time in mbsync), but it's a no-go
if you want to build a stable contributor base. do it only if the
contributor drops out or flat-out refuses.
- don't be so conservative about the types of changes you accept, in
particular when it comes to internals.
also, don't let derek have the last word too often, because, duh. :-D
greetings
