Hi Kevin,
I slept on it and my mind is clearer now, replying to email after a day of work
is never a good choice for me, replies inline :)
On Fri, Jun 30, 2017 at 04:25:11PM -0700, Kevin J. McCarthy wrote:
> Starting with a vanilla mutt tarball and adding a set of patches, broken
> out by bug fix or feature, is fairly standard practice. It's easy to
> see what is changed, and I think is still fair to call mutt.
>
> If you take a vanilla mutt tarball and add a 30k+ line "blob patch"
> called "neomutt", I don't think it's fair to call that mutt anymore.
The neomutt patch merge was done by Faidon while I was a bit off the project, in
1.6.2, when I rejoined a couple of months later this was the situation as is. He
did a huge amount of work, this is not a statement on the quality of his work or
the choices that he made, just to set the context on the situation here.
>From your statement above I understand your point clearly, I think a solution
can be found and Debian tooling provides various alternatives, I will discuss
the various options with a couple of people more expert than me on Debian
packaging and I will come back to you, this can take up to 2 weeks in the worst
case.
Due to Debian release choices we can't change the current stable (except for
very small bugfixes for functionality problems, certainly not package names or
patch structure) but we have full power on unstable/testing.
> If you don't even package a vanilla mutt tarball, but take the tarball
> from a completely different project, it most definitely is not mutt.
The only reason for the upstream switch was the code indenting changes, which
would have make the neomutt patch bigger than the mutt source code, if we could
get these in the main mutt source code that can help any proposal to restructure
the patch tree; just to clarify: I'm not saying that this is a *prerequisite*
for any proposal but this is the main reason for the upstream code switch.
Do you feel that it is possible to come up to an agreement when it comes to the
same indentation? clang-format should take care of that pretty much
automatically.
> I think it comes down to accountability. If you know the changes you
> are making, then there is something of a guarantee the result is a
> *Debian* packaged version of *Mutt*. Debian may have made some changes, but
> is vouching that this is essentially Mutt, plus changes they comprehend
> and can vouch for.
The state we are in at the moment is that we rely on Richard and the neomutt
team to understand the cause of non-trivial bugs related to patches or things on
the top of mutt, the same way I rely on you when it comes to complex changes to
the main source code.
One of the main reason why this got traction was because of the responsivity of
upstream to bug fixes / bug investigation, for what it concerns me, especially
some interactions that happened in a period of void befor both Rocco and you
became active contributors. For the Neomutt project (and I'm not speaking for
them here), I believe the issue was the same but more around the inclusion of
features.
> By switching out the tarball to someone something generated by another
> project, or adding a ginormous "blob patch", Mutt can not and should not
> vouch for it. You are relying on the other project's reputation, not
> ours. It is then completely inappropriate for you to call it mutt.
> It's not mutt. It's not "mutt + neomutt". It's neomutt.
I understand your point and I think we are reasonable people (including the
Neomutt folks) and we can find a compromise here, I only need time to think
about the various possibilities, so allow me that :)
> Perhaps lost was the wrong word. The code may be mixed in, but as Mutt
> project maintainer, the package has nothing to do with my work anymore.
> The package you are calling "mutt" is not something I've helped create.
> Your version "1.8.3+blah" is not even remotely the code I decided should
> be in version "1.8.3". It's code the NeoMutt project made the decision
> on. Is it that hard to understand why calling it mutt upsets me?
Now it's not hard anymore.
Iwould say let's proceed as follow:
* I will investigate the possible options and I will come back to both you and
Richard with one or more proposals for the future of the package in Debian.
* I know your views and I will try my best to make sure that they are
satisfied in the proposals. My understanding is that the original mutt
targz + extra feature would be OK for you as long as those features are
cleanly split in patches
* Changes will impact testing + future stable ('buster'), this is due to
Debian policy and unfortunately I cannot change that.
* You let me know whether code formatting changes can be included (in one way
or another), or whether there is a future for inclusion for those changes,
this will greatly reduce the diff between the packages.
* I will try my best to make a decision that can satisfy people involved in
both projects as much as possible, in the end I will have to make a decision
for the Debian packaging though.
I will talk to Richard and get his views, talk to some people in Debian and
formulate one or more proposals that I will circulate with both of you in a
couple of weeks.
Current situation in stale is not ideal for various reasons, all 3 of us, I
believe, dislike the stable naming as it provides wrong attribution either to
code or patches (the debian/control problem that we were discussing is now
fixed), no neomutt version number (unless you look at the changelog) and all the
other problems that you surfaced on your side.
