Re: Can we collaborate with Debian better?
Steve Langasek writes: > 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.) Thank you! I just closed that bug, and will close the other relevant ones in a bit. I don't have much more to contribute to the rest of this. Thanks again for the detailed replies. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Can we collaborate with Debian better?
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 impro
Re: Can we collaborate with Debian better?
On Mon, 2024-05-06 at 12:00 -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. Not sure if we have a recommended way, but here is what I would suggest: You could add a comment stating "This bug was fixed in $package $version in Ubuntu $version ($codename)". Afterwards ask in #ubuntu-devel or #ubuntu-bugs to close this bug. If there is a equivalent bug report in Debian, you could ask to link them. > 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? Yes, but as mentioned earlier, we are not enough Ubuntu maintainer and therefore you can easily find bug reports lingering around. So help there is welcome. You could gain the permissions. See https://wiki.ubuntu.com/Bugs and https://wiki.ubuntu.com/UbuntuBugControl -- Benjamin Drung Debian & Ubuntu Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Can we collaborate with Debian better?
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. 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? For such packages (few rdeps, nothing Ubuntu-specific; tons of these!), we don't want tighter integration between the two bug trackers? Now about mrcal. Here's how this looked from my perspective: - Mar 20. Debian FTBFS bug was filed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067398 This was a Debian bug. Unrelated to the Ubuntu release - Mar 21. mrbuild 1.9-1 uploaded to fix this bug; this fix had a small problem, so ... - Mar 26. mrbuild 1.9-2 uploaded to fix that problem as well - Apr 18. Mattias files https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069220 Sent from his Debian address. He's talking about a build fault with Python 3.12. No mention of Ubuntu at all - Apr 18. I confirm that it builds fine with Python 3.12; Matthias points at the build log on ubuntu's server. He doesn't say that this is in any way related to the 24.04 release, and this is the last I hear from him. Given the very late date, and the fact that I haven't seen any Ubuntu bugs, I assume that mrcal is in 24.04. We can see how this looks like a gap in the process, right? Yes, Matthias could have done a better job in communicating, but even so, doing the rebuild and filing a FTBFS bug on Apr 18 for the 24.04 release sounds shockingly late. Not to mention the fact that it wasn't presented at all as related to the 24.04 release, and causing the deletion of the package. Debian seems to do this much better. > "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. > 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. > 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 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. Do you think somebody else should be notified about their packages being removed? Who? Was anybody at all notified in this case? >> Related question: is there any way to get my packages included into some >> sort of noble "updates", or something like that? > > As a member of the SRU team my answer is yes, I would consider this. > It would require an actual SRU process for mrbuild, since that package > has other reverse-build-dependencies in noble (libdogleg, mrgingham, > vnlog) which should not be allowed to regress; but provided there is a > proper SRU test case to assert this, I think it's a sensible path > towards letting mrcal back in the archive for 24.04. OK. I'll look at the process now. Thank you, all. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Can we collaborate with Debian better?
On Sun, May 05, 2024 at 09:53:06PM +0200, Frank Heimes wrote: > There is a little bit more on "removing packages" here: > https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages > So it's actually a 'must' to have a LP bug for getting a package removed. The word "must" does not appear in that text. It simply says that, if you are asking for a package to be removed from Ubuntu, the process to follow is to file a bug in Launchpad. However: On Sun, May 05, 2024 at 03:03:18PM -0700, Erich Eickmeyer wrote: > I recently learned this too, and that's not entirely accurate. Apparently > we treat Debian bugs as though they're our own, so if they're filed in > Debian's bug tracker, then they're fair game. So, if a removal bug is > filed in Debian, it applies to Ubuntu as well and doesn't require a > Launchpad bug. This is broadly correct. More precisely, if there is a release-critical bug (such as a report of FTBFS) filed against the package in Debian that has caused / will cause its removal, archive admins will often consider this adequate documentation of a removal reason. Because wanting bug reports filed for package removals is largely about having something to point to in the removal messages: "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. 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, so well before, meaning this package was not pulled into Ubuntu; and mrcal COULD NOT be shipped in Ubuntu if it couldn't be built, because 2.4.1-1 was built for the wrong version of python, and 2.4.1-1build1 was built with the wrong version of xz-utils present in the host environment. So while python3.12 wasn't the cause of the build failure and this was a misdiagnosis (2.4.1-1build1 was a no-change rebuild *for* python 3.12 and it succeeded), on 2024-04-18 when Matthias removed the package we were 8 days out from release and doing everything necessary to get to the state of a Noble releasable on time without risk of compromise due to xz-utils-tainted binaries. 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. It is also understandable to me that Matthias did not prioritize communicating in the Debian bug that the issue he was reporting would result in the package's removal from the upcoming Ubuntu release. It would have been REASONABLE for Matthias to note this in the bug, but on the other hand 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. However, given the circumstances of the removal for xz-utils: > Related question: is there any way to get my packages included into some > sort of noble "updates", or something like that? As a member of the SRU team my answer is yes, I would consider this. It would require an actual SRU process for mrbuild, since that package has other reverse-build-dependencies in noble (libdogleg, mrgingham, vnlog) which should not be allowed to regress; but provided there is a proper SRU test case to assert this, I think it's a sensible path towards letting mrcal back in the archive for 24.04. -- 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
Re: Can we collaborate with Debian better?
On Sunday, May 5, 2024 12:53:06 PM PDT Frank Heimes wrote: > There is a little bit more on "removing packages" here: > https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages > So it's actually a 'must' to have a LP bug for getting a package removed. > > BR, Frank Hi Frank, I recently learned this too, and that's not entirely accurate. Apparently we treat Debian bugs as though they're our own, so if they're filed in Debian's bug tracker, then they're fair game. So, if a removal bug is filed in Debian, it applies to Ubuntu as well and doesn't require a Launchpad bug. Cheers, Erich > On Sun, May 5, 2024 at 7:32 PM Simon Quigley wrote: > > Hi Dima, > > > > As a Debian Developer myself, I understand your concerns. Processes in > > this respect could be slightly better, but it also comes down to the > > differences between the two distributions. More detailed responses inline. > > > > On 5/2/24 10:56 AM, Dima Kogan wrote: > > > Hello. > > > > > > I'm a Debian developer, and contribute to Ubuntu only indirectly: by my > > > contributions to Debian being automatically pulled into Ubuntu. But > > > since Ubuntu has more users than Debian, most of MY users use the Ubuntu > > > packages. So I'd like to talk about improving the links between the two > > > > > projects. In particular: > > Ubuntu and Debian package maintenance responsibilities are slightly > > different; in Ubuntu, members of the Core Developers team are > > collectively responsible for the packages in the Main and Restricted > > components, and Masters of the Universe are collectively responsible for > > packages in the Universe and Multiverse. The ratio of "maintainers > > holding responsibility":"packages to be maintained" is much lower in > > Ubuntu than it is in Debian. > > > > Once a package has landed in the Ubuntu archive, Ubuntu Developers now > > collectively hold responsibility for that package. We ease much of this > > work by autosyncing packages without deltas to Ubuntu in the first half > > of each cycle; that being said, we sometimes drive major transitions in > > Ubuntu before Debian, to align with our release cycle. > > > > Many Ubuntu Developers (myself included) are trained to give as much > > back to Debian as we possibly can. If we fix a package that both exists > > in Debian and has the same bug, we are encouraged to send that fix > > upstream to the Debian bug tracker (or upstream itself, or both) to > > ensure less friction when we have to merge new changes from Debian. Some > > teams within Ubuntu do not follow this process at all, but I would > > consider them the exception rather than the rule. > > > > The Debian maintainers of a package are not responsible for how their > > packages are used in Ubuntu, that's Ubuntu's responsibility. That being > > said, it is best practice to collaborate as much as we reasonably can, > > with the time we are given. > > > > > 1. Debian and Ubuntu both have separate bug trackers. But for most > > > > > > Ubuntu packages, there's no "Ubuntu" maintainer: there's just the > > > indirect one from Debian. In this case (which is most packages), > > > it's > > > unhelpful for the Ubuntu bug tracker to exist as a separate thing. > > > If > > > it must exist as a separate thing, those bugs should be forwarded > > > automatically to the Debian bug tracker. And updates (including > > > status updates) should be ingested back into the Ubuntu tracker. For > > > my packages I do try to manually look at the Ubuntu bug reports, but > > > I have no rights to close those bugs on launchpad. Probably I can > > > sign up somewhere, but as the DEBIAN developer, I shouldn't need to > > > do that. > > > > I disagree with this approach. Ubuntu and Debian are not ABI-compatible; > > Ubuntu has a slightly different toolchain than Debian, and there are > > core differences in e.g. dpkg. Not all Ubuntu bugs are Debian bugs, not > > all Ubuntu teams want their bugs sent up to Debian, and many Debian > > Maintainers don't care about Ubuntu. This is a reality of maintaining > > separate distributions. > > > > In some common cases, yes this seems reasonable, we should forward bugs > > to Debian. That being said, the first step is making sure the bug > > actually exists in the Debian-built version of the package, which is not > > always the case. > > > > Generally, I do think we can be better about triaging our bugs and > > sending what we can up to Debian. That being said, I disagree with the > > solution of completely automating it. > > > > > 2. As I just discovered, when Ubuntu rebuilds the archive for a release, > > > > > > packages that FTBFS are silently dropped. There's no bug report on > > > either of the two bug trackers. I'm upstream for a project that has > > > been excluded from 24.04 because of this gap in the process. There > > > really should be a bug report filed, so that the problem can be > > > fixe
Re: Can we collaborate with Debian better?
There is a little bit more on "removing packages" here: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages So it's actually a 'must' to have a LP bug for getting a package removed. BR, Frank On Sun, May 5, 2024 at 7:32 PM Simon Quigley wrote: > Hi Dima, > > As a Debian Developer myself, I understand your concerns. Processes in > this respect could be slightly better, but it also comes down to the > differences between the two distributions. More detailed responses inline. > > On 5/2/24 10:56 AM, Dima Kogan wrote: > > Hello. > > > > I'm a Debian developer, and contribute to Ubuntu only indirectly: by my > > contributions to Debian being automatically pulled into Ubuntu. But > > since Ubuntu has more users than Debian, most of MY users use the Ubuntu > > packages. So I'd like to talk about improving the links between the two > > projects. In particular: > > Ubuntu and Debian package maintenance responsibilities are slightly > different; in Ubuntu, members of the Core Developers team are > collectively responsible for the packages in the Main and Restricted > components, and Masters of the Universe are collectively responsible for > packages in the Universe and Multiverse. The ratio of "maintainers > holding responsibility":"packages to be maintained" is much lower in > Ubuntu than it is in Debian. > > Once a package has landed in the Ubuntu archive, Ubuntu Developers now > collectively hold responsibility for that package. We ease much of this > work by autosyncing packages without deltas to Ubuntu in the first half > of each cycle; that being said, we sometimes drive major transitions in > Ubuntu before Debian, to align with our release cycle. > > Many Ubuntu Developers (myself included) are trained to give as much > back to Debian as we possibly can. If we fix a package that both exists > in Debian and has the same bug, we are encouraged to send that fix > upstream to the Debian bug tracker (or upstream itself, or both) to > ensure less friction when we have to merge new changes from Debian. Some > teams within Ubuntu do not follow this process at all, but I would > consider them the exception rather than the rule. > > The Debian maintainers of a package are not responsible for how their > packages are used in Ubuntu, that's Ubuntu's responsibility. That being > said, it is best practice to collaborate as much as we reasonably can, > with the time we are given. > > > 1. Debian and Ubuntu both have separate bug trackers. But for most > > Ubuntu packages, there's no "Ubuntu" maintainer: there's just the > > indirect one from Debian. In this case (which is most packages), it's > > unhelpful for the Ubuntu bug tracker to exist as a separate thing. If > > it must exist as a separate thing, those bugs should be forwarded > > automatically to the Debian bug tracker. And updates (including > > status updates) should be ingested back into the Ubuntu tracker. For > > my packages I do try to manually look at the Ubuntu bug reports, but > > I have no rights to close those bugs on launchpad. Probably I can > > sign up somewhere, but as the DEBIAN developer, I shouldn't need to > > do that. > > I disagree with this approach. Ubuntu and Debian are not ABI-compatible; > Ubuntu has a slightly different toolchain than Debian, and there are > core differences in e.g. dpkg. Not all Ubuntu bugs are Debian bugs, not > all Ubuntu teams want their bugs sent up to Debian, and many Debian > Maintainers don't care about Ubuntu. This is a reality of maintaining > separate distributions. > > In some common cases, yes this seems reasonable, we should forward bugs > to Debian. That being said, the first step is making sure the bug > actually exists in the Debian-built version of the package, which is not > always the case. > > Generally, I do think we can be better about triaging our bugs and > sending what we can up to Debian. That being said, I disagree with the > solution of completely automating it. > > > 2. As I just discovered, when Ubuntu rebuilds the archive for a release, > > packages that FTBFS are silently dropped. There's no bug report on > > either of the two bug trackers. I'm upstream for a project that has > > been excluded from 24.04 because of this gap in the process. There > > really should be a bug report filed, so that the problem can be fixed > > before the release (what Debian does for their releases). And this > > should be filed on the Debian bug tracker, if that's where the > > maintenance happens. > > This entirely falls on the Ubuntu Archive Administrators. To my > understanding as an Ubuntu Developer, if we want a package removed, it > is best practice to either have a Debian removal bug or an Ubuntu > removal bug explaining the rationale. Whether this is enforced is up to > the Archive Administrator doing the removal, since the only known public > documentation says nothing about filing bugs: > https://wiki.ubunt
Re: Can we collaborate with Debian better?
On Sun, May 5, 2024 at 3:12 AM Dima Kogan wrote: > 2. As I just discovered, when Ubuntu rebuilds the archive for a release, >packages that FTBFS are silently dropped. There's no bug report on >either of the two bug trackers. I'm upstream for a project that has >been excluded from 24.04 because of this gap in the process. There >really should be a bug report filed, so that the problem can be fixed >before the release (what Debian does for their releases). And this >should be filed on the Debian bug tracker, if that's where the >maintenance happens. Visit https://launchpad.net/ubuntu/+source/mrcal and click "View publishing history". Click the drop down arrow next to the most recent Deleted entry. It says that Matthias Klose deleted the package and it points to a Debian bug number. That Debian bug was filed by Matthias on that day. Unfortunately, at that point there was very little time before the Ubuntu 24.04 LTS release and manual work was necessary to fix the bug. mrcal was caught up in the mass rebuild required for xz-utils mitigation, which meant that it needed to be buildable or it was not possible to include it in the Ubuntu 24.04 LTS release. mrcal was uploaded to Debian in February but mrbuild 1.9 and 1.10 weren't uploaded until weeks later, after Debian Import Freeze when autosyncs are stopped. https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649 https://discourse.ubuntu.com/t/oracular-oriole-release-schedule/36460 Thank you, Jeremy Bícha -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Can we collaborate with Debian better?
Hi Dima, As a Debian Developer myself, I understand your concerns. Processes in this respect could be slightly better, but it also comes down to the differences between the two distributions. More detailed responses inline. On 5/2/24 10:56 AM, Dima Kogan wrote: Hello. I'm a Debian developer, and contribute to Ubuntu only indirectly: by my contributions to Debian being automatically pulled into Ubuntu. But since Ubuntu has more users than Debian, most of MY users use the Ubuntu packages. So I'd like to talk about improving the links between the two projects. In particular: Ubuntu and Debian package maintenance responsibilities are slightly different; in Ubuntu, members of the Core Developers team are collectively responsible for the packages in the Main and Restricted components, and Masters of the Universe are collectively responsible for packages in the Universe and Multiverse. The ratio of "maintainers holding responsibility":"packages to be maintained" is much lower in Ubuntu than it is in Debian. Once a package has landed in the Ubuntu archive, Ubuntu Developers now collectively hold responsibility for that package. We ease much of this work by autosyncing packages without deltas to Ubuntu in the first half of each cycle; that being said, we sometimes drive major transitions in Ubuntu before Debian, to align with our release cycle. Many Ubuntu Developers (myself included) are trained to give as much back to Debian as we possibly can. If we fix a package that both exists in Debian and has the same bug, we are encouraged to send that fix upstream to the Debian bug tracker (or upstream itself, or both) to ensure less friction when we have to merge new changes from Debian. Some teams within Ubuntu do not follow this process at all, but I would consider them the exception rather than the rule. The Debian maintainers of a package are not responsible for how their packages are used in Ubuntu, that's Ubuntu's responsibility. That being said, it is best practice to collaborate as much as we reasonably can, with the time we are given. 1. Debian and Ubuntu both have separate bug trackers. But for most Ubuntu packages, there's no "Ubuntu" maintainer: there's just the indirect one from Debian. In this case (which is most packages), it's unhelpful for the Ubuntu bug tracker to exist as a separate thing. If it must exist as a separate thing, those bugs should be forwarded automatically to the Debian bug tracker. And updates (including status updates) should be ingested back into the Ubuntu tracker. For my packages I do try to manually look at the Ubuntu bug reports, but I have no rights to close those bugs on launchpad. Probably I can sign up somewhere, but as the DEBIAN developer, I shouldn't need to do that. I disagree with this approach. Ubuntu and Debian are not ABI-compatible; Ubuntu has a slightly different toolchain than Debian, and there are core differences in e.g. dpkg. Not all Ubuntu bugs are Debian bugs, not all Ubuntu teams want their bugs sent up to Debian, and many Debian Maintainers don't care about Ubuntu. This is a reality of maintaining separate distributions. In some common cases, yes this seems reasonable, we should forward bugs to Debian. That being said, the first step is making sure the bug actually exists in the Debian-built version of the package, which is not always the case. Generally, I do think we can be better about triaging our bugs and sending what we can up to Debian. That being said, I disagree with the solution of completely automating it. 2. As I just discovered, when Ubuntu rebuilds the archive for a release, packages that FTBFS are silently dropped. There's no bug report on either of the two bug trackers. I'm upstream for a project that has been excluded from 24.04 because of this gap in the process. There really should be a bug report filed, so that the problem can be fixed before the release (what Debian does for their releases). And this should be filed on the Debian bug tracker, if that's where the maintenance happens. This entirely falls on the Ubuntu Archive Administrators. To my understanding as an Ubuntu Developer, if we want a package removed, it is best practice to either have a Debian removal bug or an Ubuntu removal bug explaining the rationale. Whether this is enforced is up to the Archive Administrator doing the removal, since the only known public documentation says nothing about filing bugs: https://wiki.ubuntu.com/ArchiveAdministration#Removals To say that packages that FTBFS are indiscriminately removed during transitions ignores the fact that usually, we do have to file a bug if we want an AA to remove a package. I don't know how hard the above is, but the current situation isn't great for either of us. Related question: is there any way to get my packages included into some sort of noble "updates", or something like that?
