Re: [jmtd@xxxxxxxxxx: Bug#870635: mutt package is not using the official mutt tarball]
- Date: Mon, 20 Nov 2017 06:59:51 +0000
- From: Antonio Radici <antonio@xxxxxxxxxx>
- Subject: Re: [jmtd@xxxxxxxxxx: Bug#870635: mutt package is not using the official mutt tarball]
[It turns out that hitting 'g' on mutt replies the original CC, copy paste of my
On Fri, Nov 17, 2017 at 04:46:21PM +0000, Jonathan Dowland wrote:
> Bcc: Subject: Re: Bug#870635: mutt package is not using the official mutt
> Reply-To: In-Reply-To: <20171111074105.iz5bje4kgkl3qsp2@xxxxxxxxxxxxxxxxxx>
> CCing -devel because I think this might be of wider interest.
> Firstly, the existing package is neomutt, but called mutt. So the
> existing package users are neomutt users, and the existing reported bugs
> are bugs in neomutt. (The wisdom of having moved the package *to*
> neomutt at this point is irrelevant, because it has happened whether we
> like it or not.) If you are suggesting that the package name "mutt" is
> going to be real "mutt" in future, then what happens to existing
> users? What are their expectations? Do you reassign all existing bugs to
> a new neomutt package name? Do you attempt to triage all bugs to figure
> out whether they apply to one, the other, or both? Would users who are
> using neomutt features not find the change to be a regression from their
> point of view?
I think this is the most problematic point and one of the reason against having
a mutt package that is not a transitional package, despite that I still believe
that we need a 'neomutt' package, this need was raised by the mutt maintainer,
we cannot continue to distribute something called mutt where the source code
comes from another package, which is now completely different.
To provide more context: initially we shipped neomutt as a patch on the top of
the original mutt source code, then at some stage the neomutt team (it is in
thei right) to format their code in a consistent way across all files, so the
neomutt patch became bigger than the mutt source code, which is why I switched
to the neomutt tarball. That was the first and last upload with the neomutt
tarball (also the last upload for neomutt).
The original mutt maintainer raised the point that we cannot call the mutt
package as 'mutt' if the source comes from another package, especially since he
disagrees with some technical choices of the other package, so I think his
reasoning is correct.
> Secondly, is there a need for both mutt and neomutt in Debian? Our
> mission is not to package every piece of software on earth, but to build
> a useful operating system. Is there sufficient distinction between the
> two, from a user's perspective, that there is a genuine need for both in
> the archive? (Of course, the distinction is very important for the
> authors of the software. But that's not the same thing.) For enough
> users to justify the work? I've been a daily mutt (and now neomutt) user
> in Debian for nearly 20 years, and I don't think there is.
In an ideal world yes, in a real world where the maintenance is done by humans
> Thirdly, let's look honestly at how well the existing package maintenance
> is working. This particular issue was raise in late June, and you
> said at the time that'd you have come up with a transition plan within a
> couple of weeks. For my pet neomutt bug (which coincidentally I
> reported at around the same time) you expected to have the patch applied
> shortly, possibly even within a week, but it remains unfixed.
Unfortunately some non-Debian related commitments trumped my plans; yes I could
have uploaded bugfixes as I did in the past but I made a commitment to Kevin
(original mutt maintainer) to solve the source code issue first. Unfortunately
no easy solution is in sight, so for the benefit of the users I think that it is
better to have mutt as transational package + neomutt.
> I am not trying to criticise your personal contributions to Debian. We
> are all volunteers, and we all do what we can and nobody should expect
> more from us than we are prepared or able to give. I am extremely
> grateful for the work you have done and continue to do. But I think it's
> important to communicate as realistically as possible what we are able
> to do. I am very guilty of getting this wrong, and over-promising and
> under-delivering for my own efforts in Debian. I simply wish to point
> out that the existing Mutt packaging team appears to be stretched. It
> seems to me that having two mutt packages to manage is only going to
> make this situation much worse.
The existing Mutt packaging team it's just me for some time now, I had a similar
slow period in the past (I was the only maintainer at the time) and we ended up
with the decision of switching to neomutt, decision which I'm still trying to
sort out years later. I'm not trying to blame anyone here, I think who
contributed at the time did a fantastic work; the fact remains that the current
situation is not good for the maintainer of the upstream mutt package and it
needs to be fixed.
Thanks a lot for your feedback, it is very valuable. My last commitment, which
in theory should work, is to fix this situation before the end of the month. I
know that at this point in time this is '10 days from now', but I still plan to
work on it and fix the issue.
Pkg-mutt-maintainers mailing list