request for stable release exception: ubuntu-dev-tools

[Steve Langasek]

Robie has given a verbal ack for this exception on IRC.

In parallel, Brian has pointed out that there was *already* an approved SRU
exception on ubuntu-dev-tools, from 2 years ago, which I overlooked.

  https://wiki.ubuntu.com/ubuntu-dev-tools-Updates

I believe the exception I've proposed here is broader than the earlier one
and is therefore lighter weight on the SRUer and the SRU team, so I'm going
to swap out the link on the wiki.  If anyone sees something from the earlier
exception that isn't covered by the new one but should be, please shout.

Thanks!
-- 
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 at ubuntu.com                                     vorlon at debian.org


On Tue, May 30, 2023 at 12:37:52PM -0700, Steve Langasek wrote:
> Hello,
> 
> Most immediately prompted by the discovery that an attempt to SRU
> debootstrap runs afoul of a difference in behavior in mk-sbuild between
> karmic and earlier releases[1], I have gotten around to drafting a proposed
> SRU exception for the ubuntu-dev-tools package:
> 
>   https://wiki.ubuntu.com/UbuntuDevToolsUpdates
> 
> While it's proper that ubuntu-dev-tools be provided as a deb in the
> distribution, the normal SRU process is a poor fit for this package.  We
> should provide consistent tooling to Ubuntu developers regardless of which
> release they're running on top of.
> 
> The fact that we haven't had such an SRU exception in place means that
> ubuntu-dev-tools has been allowed to atrophy, because we couldn't rely on
> all Ubuntu developers having timely access through that package to new
> tooling without doing a bunch of extra work - so tools have wound up
> distributed by other suboptimal methods (e.g. the
> retry-autopkgtest-regressions tool, which is in lp:ubuntu-archive-tools
> despite in no way being specific to Archive Admin privileges).
> 
> I raised the question on ubuntu-devel last year of where to distribute such
> tools, without a satisfactory conclusion to the discussion[2].  This is my
> proposed answer.
> 
> Why not a snap?
> ---------------
> Snaps address the question of release-agnostic distribution of software. 
> But since the ubuntu-dev-tools package defines *the* Ubuntu developer
> experience, it's important that all core-devs be able to make changes to it. 
> The lack of Launchpad group integration in the Snap Store would impose an
> unacceptable publishing bottleneck.
> 
> By its nature, ubuntu-dev-tools would also either need to be a classic snap,
> or be granted an interface with broad filesystem privileges, neither of
> which makes it a particularly good fit for the snap model.
> 
> Thanks,
> -- 
> 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 at ubuntu.com                                     vorlon at debian.org
> 
> [1] https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/2020530
> [2] https://lists.ubuntu.com/archives/ubuntu-devel/2022-April/041996.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20230530/44f62513/attachment.sig>