On Fri, Jun 30, 2017 at 10:54:16AM -0700, Kevin J. McCarthy wrote: > Here's the thing. Your tarball is not just Mutt 1.8.3 + some NeoMutt > stuff. It includes most everything in my development (default) branch > for 1.9.0 as of 20170609. Stuff that hasn't had time to bake, or that I > feel I have the right to change. > > NeoMutt pulls all the stuff out of *my* default branch, packs it in, and > gives to you as if it were extra NeoMutt "goodness". > > With the new release numbering, I try very hard to keep the "patch" > versions, e.g. 1.8.[1-3], as bug-fix only releases. They are released > out of the "stable" branch. By calling your package "mutt 1.8.3", > regardless of what extra version labels you attach, you are reflecting > on me and making my efforts at stable releases irrelevant.
The 'stable' process in Debian is different, the version that is currently in stretch has been there for many months (1.7.2), at most the latest version of mutt + neomutt patches will get to testing, which will become the 'stable' one in many years. The package is called mutt, even if it is called neomutt it will ship mutt as binary package (because they both ship the same binary), the current versioning provides the correct attribution IMHO > As you know, the same thing happened with 1.6.2, when you first started > incorporating NeoMutt. Your NeoMutt patches included half implemented > features from 1.7.0 development, and was broken. I will be happy to understand what we are trying to achieve and mediate between the parts if possible. Is it about having a package that contains *only* the mutt source code as you release it? It was never like this even before 1.6.*, when we had extra patches on the top of mutt, what should I do with patches/features which are (and were) expected on the top of mutt? > > [...], I'll be open to reconsider this if/when the neomutt devs stop > > rebasing their changes from the latest mutt source tarball. > > This furthers my point: if NeoMutt drives your decisions as a packager, > you should name your package neomutt. I've always talked to both you and Richard, and I've always found both of you to be reasonable individual, neomutt *does not* drive my decision as a packager, I was trying to present a hypothetical scenario. > > I know it is not simple to add a feature to the main code base because > > certain > > standards have to be respected and some patches might generate undesiderable > > side effect; at the same time Debian users have grown used to features that > > have > > been there even before I started maintaing mutt (compressed folders, > > sidebar, > > etc) so I have to play a balancing act there. > > You mean the compressed folders that I fixed up and included in 1.8.0? > Or the sidebar I spent a huge amount of effort fixing and included in > 1.7.0? Wait, I must be mistaken, https://packages.debian.org/sid/mutt > says those are NeoMutt additions. At the time when the debian/control was modified (two years ago) those were neomutt addition, obviously now they are part of the main codebase, so they should not be presented as neomutt addition. It seems a bug to me and I will take care of fixing the control to ensure proper attribution. There is no malicious intent here, mistakes can happen unfortunatel > > I might have made some mistakes in the past so I'm sorry if I caused > > extra work on your side, but it is my intention to do a fair amount of > > investigation work before reporting any bug. > > The problem is not in your triaging, but that not every user picks up on > the distinction when you call your package mutt. People show up in the > IRC channel or mutt-users, or submit tickets directly. Then I end up > trying to debug a problem that isn't even in the version they purport to > be using. You should point Debian users to http://bugs.debian.org/mutt, where their problems will be triaged properly and tickets will be created if needed. > I understand your point about the extra work involved in multiple > packages. But it is disrespectful to me for Debian to label a *fork's* > tarball as the package "mutt". It is frustrating and demotivating that > all my work towards resuscitating mutt is lost and mislabeled to the > huge user base encompassed by Debian and all its derivatives. I don't believe that your work is lost, all your code ends up in Debian (and derivatives) and yes there will be patches on the top of it. Unfortunately I do not have time or willingness to use in possible a flame around naming and what is or is not a fork; I will continue to collaborate with both you and Richard, as usual.
