Can we collaborate with Debian better?

Sun May 5 22:03:18 UTC 2024

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 <simon at tsimonq2.net> 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.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?
> > > 
> > > I'm looking at the "mrcal" source package that had an ininteresting
> > > FTBFS bug due to some dependency changing its interface. There was a
> > > Debian bug report filed and quickly fixed, but this happened too late
> > > 
> > > for noble:
> > >    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067398
> > > 
> > > The fix is to update the "mrbuild" package to at least 1.9. Is it
> > > possible to get an updated "mrbuild" and "mrcal" into 24.04?
> > > 
> > > If I'm misinterpreting what's going on, please let me know. Right now I
> > > 
> > > see this:
> > >    dima at shorty:~$ rmadison -u ubuntu mrbuild | grep noble
> > >    
> > >     mrbuild | 1.8-1 | noble/universe    | source, all
> > >    
> > >    dima at shorty:~$ rmadison -u ubuntu libmrcal-dev | grep noble
> > >    
> > >     libmrcal-dev | 2.4.1-1build1 | noble-proposed/universe    | arm64,
> > 
> > ppc64el, riscv64
> > 
> > > The latest mrcal IS 2.4.1, but here it's in "noble-proposed" and not for
> > > amd64 for some reason.
> > 
> > I would highly suggest filing a bug against the package in Launchpad
> > following the Stable Release Update procedure:
> > https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
> > 
> > If you can articulate your case and the rationale for the update well,
> > it is unlikely that it will be rejected.
> > 
> > Best regards,
> > --
> > Simon Quigley
> > simon at tsimonq2.net
> > @tsimonq2:ubuntu.com on Matrix
> > tsimonq2 on LiberaChat and OFTC
> > 5C7A BEA2 0F86 3045 9CC8
> > C8B5 E27F 2CF8 458C 2FA4
> > 
> > --
> > ubuntu-devel mailing list
> > ubuntu-devel at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
Erich Eickmeyer
Ubuntu MOTU
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20240505/bfc79cf1/attachment.sig>