On Mon, May 06, 2024 at 12:00:28PM -0700, Dima Kogan wrote:
> Thanks for the replies, everybody. This was helpful.
> First off, let me ask about the bug tracker divergence. There are a
> number of bugs in Ubuntu launchpad, describing issues that have long
> been fixed in Debian. For instance:
> https://bugs.launchpad.net/ubuntu/+source/vlfeat/+bug/1313166
> I'm not the Ubuntu maintainer, so I can't close these bugs.
You do not have to be "the Ubuntu maintainer" to close bugs in launchpad,
you only have to create a launchpad account. (Some bug states, such as
'Triaged' and 'Opinion', are restricted; but 'Fix Released' is not.)
> Are yall saying that it's the responsibility of the Ubuntu maintainers to
> close these, and they just haven't gotten around to it yet?
I think "responsibility" is a bit strong. We have processes by which the
Ubuntu community, not only limited to developers, can contribute to triaging
bugs:
https://wiki.ubuntu.com/BugSquad/GettingInvolved
But the primary purpose of the bug tracker, and bug triage, is not to have a
perfect representation of the bug status of packages. The primary purpose
is to use this as input to improve the quality of packages for our users.
If a bug is filed against a package that's in universe, and which is synced
from Debian (both of these things are true for vlfeat), it is very unlikely
that a developer is going to look at and act on that bug report. This
unfortunately means it may be a waste of time for a user to have filed that
bug report at all. But we don't have a way to communicate to users that
some bugs should probably be filed upstream (where "upstream" may mean
Debian) instead.
> For such packages (few rdeps, nothing Ubuntu-specific; tons of these!), we
> don't want tighter integration between the two bug trackers?
I think by "tighter integration" you are implying automation of bug status
changes, and for that the answer is no. Even in cases where we know a
corresponding bug in the Debian BTS and have linked to it for the launchpad
bug for the Ubuntu package, there are various ways in which trying to make
the Ubuntu bug state match the Debian bug state can go wrong. The bugfix
may not have landed into Ubuntu because of a freeze; or may have been synced
to Ubuntu, but had an Ubuntu-specific build or test failure preventing it
from migrating to the release pocket (and therefore the bug is not actually
fixed from a user perspective); there may be Ubuntu-specific aspects to the
bug that mean the fix in Debian is not applicable to Ubuntu. So automation
here is going to have an unacceptable false-positive rate.
The automation we DO have, and have had for many years, is that where a
Debian maintainer knows a change they're making in the package fixes a bug
reported in Ubuntu, they can close that bug in the changelog just as they
can close a Debian bug using the LP: ##### syntax.
> > "Removed from disk on 2024-04-18.
> > Removal requested on 2024-04-17.
> > Deleted on 2024-04-17 by Matthias Klose
> > Debian #1069220, ftbfs, no rdeps"
> > https://launchpad.net/ubuntu/+source/mrcal/+publishinghistory
> > In this case, the bug pointed to is in fact one that Matthias himself
> > filed, so he was documenting the build failure for the Debian
> > maintainer prior to removing the package.
> I guess he did that, but I never saw any of it.
Yes, there is no way to subscribe in Ubuntu to package removals.
If a bug had been filed in Ubuntu about it, you could subscribe to bug
notifications for the package (in fact, if you claim your @debian.org email
address in Launchpad, you will be autosubscribed to bugs for packages you
maintain). But that didn't apply here.
> > mrbuild 1.10-1, which would have fixed this build failure, was published to
> > Debian unstable on 2024-04-05. However, Debian Import Freeze happened on
> > 2024-02-29
> As noted above, mrbuild 1.9-2, published on Mar 26 fixed this problem
> (and 1.9-1, published on Mar 21 would probably have fixed it too). These
> both made the deadline.
Which deadline? As I said above, Debian Import Freeze was Feb 29, a month
before.
> > So although you did reply right away with an explanation of how to fix
> > the build failure, it's understandable that Matthias did not
> > prioritize bringing this package back into the noble release pocket
> > and syncing the new mrbuild necessary to get it to build in the week
> > before release, when many other things were in flight.
> Yeah. The timing of the xz disclosure was really unfortunate. It sounds
> like the extra work should have pushed back the Ubuntu release. Even if
> the communication was clear here, the time crunch made it impossible to
> actually fix the problem.
I don't think the removal of mrcal from Ubuntu supports the conclusion that
the release should be delayed. I appreciate that you care about your work
being used by users of Ubuntu and care about its inclusion, and *in general*
there are things we could do to improve Debian maintainers' ability to track
whether a package is at risk of removal (e.g. perhaps we should be
automatically surfacing build failures of a package as bugs in launchpad, so
that a package bug subscription would be enough to result in a
notification). But it is always the case that we may do late removals of
packages in a development series, when necessary to address certain classes
of problems (most likely: uninstallability of binary packages) and don't
currently have a plausible way to generate notifications to Debian
maintainers for these cases.
> > I do not want to commit our archive admins to a policy that we MUST
> > notify Debian maintainers before their packages are removed from
> > Ubuntu.
> I think that would be a very good policy, actually.
You *personally* think that there should be such a policy. Many other
Debian maintainers would be very angry to receive such notifications. And
we currently don't have any mechanism for such notifications that would not
impose an additional burden on the archive admins, which I'm not willing to
accept.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
