Bug#841294: Overrule maitainer of "global" to package a new upstream version
On Fri, Dec 09, 2016 at 08:58:10AM -0500, Sam Hartman wrote:
> In the language similar to the IETF, used only because we're both familiar with
> it, the technical issues surrounding global-6 and the question of
> evidence regarding htags have been considered. My judgment of the
> discussion is that the rough consensus here is that those issues are not
> significant compared to failing to upgrade global in six years. That
> is, we in this discussion have reach an informed opinion that those
> issues are not significant enough to block. It is my opinion you are in
> the rough.
>
> I think the question before the TC is (and is properly) how should
> global-6 be maintained and whether you are the person to do that.
>
> You have tried to frame it arguing that the version number doesn't
> matter.
> I absolutely agree.
> However, the time at which Debian has last synced with upstream does
> matter.
> Six years is a long time.
> Moreover, I believe that the standard you've used to evaluate whether
> failing to sync for six years was acceptable is inconsistent with best
> practices of the project.
As a maintainer who has sometimes had cause to do similar things, I'm
concerned at the standard being applied here. Could you perhaps review
the history around groff 1.18.1.1 -> 1.20 for comparison? This is a
case that's all over and done with seven years ago, so should be free of
emotive associations by now, and the history can be read through
reasonably quickly.
Here are some references:
https://bugs.debian.org/196762
https://bugs.debian.org/374569
https://lists.gnu.org/archive/html/groff/2007-11/msg00011.html
Now, my perception of this case is that there was a complex blocking
issue with the new upstream release that affected a minority of users,
and therefore I chose to hold back the new upstream until it could be
handled in a way that did not cause serious regressions. Eventually, by
dint of help from quite a few people, we managed to get it sorted out to
everyone's satisfaction. I think I acted as a responsible maintainer,
even though I wasn't perhaps as energetic as might have been ideal and
not everyone was happy with me along the way.
But, if you so chose, you could take the history and frame it in quite a
different way. In that view, I held back substantial upstream changes
for over six years despite many requests from users to upgrade, in bug
reports, mailing list posts, and personal appeals at conferences,
pleading regressions affecting only a small minority of users. Despite
presenting a superficial appearance of wanting help, I dithered for many
months between status updates, causing RC bugs along the way. A
different maintainer should have been appointed who would have uploaded
groff 1.19, perhaps as a separate source package, and left the CJK users
to maintain the old fork for themselves.
Does that sound familiar?
Now, it's clear which view of events I prefer in the groff case, and I'm
not trying to say that the same thing applies in the global case (to be
quite honest, I've not spent the time required to read the history there
well enough to form a view; one advantage to having quit the TC is that
I get to ignore this sort of thing if I feel like it :-) ). However, I
am concerned about the "don't sync with upstream for six years so you're
a negligent maintainer" principle apparently being formed here, because
from my own history I feel that there can in fact be good reasons for
that.
If the TC thinks my actions in the past were reasonable, then I would
like any ruling here to be a bit more nuanced about cases of delayed
syncing with upstream, reflecting whatever important differences you see
between the two cases.
Thanks,
--
Colin Watson [cjwatson@debian.org]
Reply to: