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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel