On Fri, Jun 30, 2017 at 07:03:22AM +0000, Antonio Radici wrote: > I agree that the naming + versioning is confusing but I've sorted that out > since > we switched .tar.gz from usptream a week ago, not +neomutt2017xxxx is in the > version, for example the latest version of mutt is 1.8.3+neomutt20170609-2. > The main reason for the switch was that they have standardized code indenting, > therefore a theoretical neomutt patch would have been bigger than the source > code itself.
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. 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'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 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. > 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. 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. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
