On Mon, May 30, 2016 at 06:42:21PM +0200, Elimar Riesebieter wrote: > I've contacted Antonio Radici, Christoph Berg, "Matteo F. Vescovi" and > Faidon Liambotis via PM a while ago.
I'll respond here, unfortunately without not much context, as that was a PM and I wouldn't want to forward without permission. So, first of, a bit of a background for the ITP: - The mutt maintainers have been engaging with the neomutt upstream already. I, in fact, joined the mutt maintainer group precisely for this purpose. See https://github.com/neomutt/neomutt/issues/23 and others. - Debian is already shipping neomutt partially already; mutt 1.6.1-1 already replaces some of our home-grown patches with neomutt's. - Debian has *not* been shipping a vanilla mutt for years. Debian has been shipping mutt, mutt-patched and mutt-kz, the former two from src:mutt and the latter from src:mutt-kz. All of them, including the binary package called "mutt" are heavily patched, to a large extent with patches that neomutt ships (ifdef, compressed folders, trash/purge) but a lot of others as well. - The neomutt upstream (Cc'ed) has been incredibly responsive and receptive to requests, both in general and to Debian's needs specifically. Besides us, he's been bringing together many other downstreams (distros and BSDs). - Considering the above, consensus between the mutt maintainers so far (and AIUI) has been that the mutt source package should switch upstreams and start tracking neomutt. This would basically mean having *one* source and *one* binary package for mutt in Debian (not counting transitional packages). - This has been waiting to some extent on the new neomutt release which includes compressed folders and NNTP, released just today. As such, I think this ITP is superfluous, at least for now. Even if it is not, pkg-mutt should own this ITP, not Elimar alone -- as we are already the de facto downstreams of neomutt in Debian. We could certainly revisit the decision to ship two source packages in Debian, src:mutt and src:neomutt (the eventual deprecation of mutt-patched and src:mutt-kz is widely agreed at this point, I think). I still haven't heard a convincing response of what would happen to the "mutt" binary package, though. As I explained above, we're not shipping a vanilla mutt and haven't been doing so for many years now. Switching back to the vanilla mutt would be a regression at this point and break user expectations on upgrades. Keeping the status quo, on the other hand, would mean just a huge waste of effort for maintaining and forward-porting patches that neomutt upstream is already doing a better job at. I also haven't heard a convincing response on what would happen with all of the patches shipped in src:mutt's debian/patches that are not in neomutt yet; effectively forking off the two packages would suck for either future maintenance or for our users' upgrades, both of which I find unacceptable options. What do others think? Regards, Faidon
