Le vendredi, 9 décembre 2016, 15.03:14 h CET Colin Watson a écrit :
> On Fri, Dec 09, 2016 at 08:58:10AM -0500, Sam Hartman wrote:
> > 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.
Thank you for the example case, including its references.
> 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.
>
> (…)
>
> 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.
By a quick glance, your past actions _were_ indeed reasonable. And commenting
on what differentiates this example with 'global' is a worthwile exercise.
What I see as fundamental difference here was your use of #196762 as a single
point of contact for the problem you were facing with groff 1.19, in which you
explained, commented and followed up on what the problem was, what were your
thoughts, asking for help, and updating this bug regularly. You also used this
single point of contact in later bugs:
> Unfortunately, for technical reasons (see bug #196762), it is extremely
> difficult to upgrade to the new upstream release.
All-in-all, although there are appeareances of equivalence between the two
packages' histories, I certainly see fundamental differences in how the "new
upstream version has problems that are hard to fix" question was addressed.
There can be valid, strong and solid technical reasons to hold back on new
upstream versions, but what matters for us as a distribution, is how we
collaborate and communicate about these blockers. Our SC's "We will not hide
problems" is not to be understood strictly as "our bugtracker is public" only;
it is a much larger concern that we should share, so as to make our
collaboration as frictionless as possible, as well as make the technical
problems not only reside in the package maintainer's heads, but to share them
with the project.
That's really the thing I miss most in 'global's history: it shouldn't need a
TC bug to get the 'htags' problem described properly, on a public, standalone
bug.
Things like
> (we) are currently discussing changes to the CGI mechanism which may alter
> several things about how this is currently arranged.
in #590053, or the discussion in #574947 where Ron claims to have reached a
private agreement that is not confirmed by upstream authors are un-
comprehensible for outsiders, which are left without a clue upon what needs to
be fixed, or done.
The problem I have with how 'global' is maintained is not at all technical.
Holding back on an old version because of 'htags' breakage _was_ a good
technical decision back then. But the way this hurdle was (not) documented is
just not how I want to see maintainers collaborate and "not hide problems" for
packages in Debian.
The fact that the hurdle is _still not_ properly and publicly documented
doesn't open room for helping the maintainer, doesn't bring clarity to
newcomers and therefore puts the maintainer in sole responsiblity. Wei Lui
expressed that problem clearly in #816924 (March 2016):
> I'm aware of the disagreement between Ron and Shigio, but it's so
> frustrating that no resolution has been found for so many years. There
> were talks about possible designs proposed by Ron and / or Shigio but
> it is just impossible for us users to do archaeology dating back to
> 1999 with no useful references whatsoever.
Another difference I see is this urge you felt. Two months after groff 1.19
was released, you filed this bug documenting your concerns with it and no less
than three months later, you wrote:
> I'm beginning to get a bit itchy about falling too far behind upstream
> here.
As a matter of fact, I do _expect_ maintainers to get itchy when they fall too
far behind upstream. If Ron had documented the problem from the start (or at
any later point in time, really), users would have found it, and debated ways
out, patches, etc. This bug would have included upstream developers for a
discussion _in public_. That bug would have helped joining forces, helped the
maintainer determine the best consensus to adopt.
And it wouldn't have needed a long TC discussion.
--
Cheers,
OdyXAttachment:
signature.asc
Description: This is a digitally signed message part.