Hi Robie, Indeed, this is a great idea that could be used in other teams. I have been wanting a more automated way of updating the Ubuntu Studio bug subscriptions. And I would rather not build something special.
If I was to create the Ubuntu Studio bug subscription list in the yaml file from scratch, I would want to take the package names from the Package Set, which is also in Launchpad. Maybe a function to compare the two and propose a commit with new packages from the package set? But are the team names the same in both cases? Just food for thought. Regards, Ross On 12/14/21 4:53 PM, Robie Basak wrote: > Dear Archive Team, > > On the Server Team, we've started to use git to manage our team > subscriptions to packages in Launchpad. The main reasons are: > > 1) To avoid inadvertent changes - we lost a bunch of subscriptions by > accident at one point. > > 2) To keep an audit trail of changes made. > > This is particularly important for the server team as we have an > effective bug triage process now that is able to stay on top of all new > bug traffic for all our subscribed packages. Accidentally losing a > subscription causes bug traffic to miss our bug triage process, which > includes tracking new activity on previously triaged bugs. > > We're achieving this with the script at this repository, which also > contains our canonical list of subscriptions: > https://git.launchpad.net/~canonical-server/+git/team-subscriptions > > The script just ensures that Launchpad's view matches our "officially > subscribed" list that we keep there in git. Changes made in Launchpad > that aren't committed in git get reverted automatically. > > The requirement from us is simply that the git repository be updated > with any changes to our subscriptions with a suitable commit message to > provide an explanation. Otherwise changes intentionally get reverted. > > When I arranged this, it didn't occur to me that anybody other than us > touches our package subscriptions on Launchpad. But apparently you do, > when making changes for technicalities like versioned source package > names (see below for the thread with an example). I didn't even realise > that you had an ACL that permitted you to do so directly, thinking that > the request always went via our team in the past. > > However if your expectation is that you can JFDI in Launchpad itself, > then this clashes with our desire for the audit trail. > > On the other hand, I don't expect to be forcing this onto other teams, > and so having a different workflow for you to follow depending on which > team it is will also clearly be a pain. > > Any suggestions on how to proceed? > > Note that the script is deliberately generic and so other teams could > adopt it too if they wish. And of course we can move the repository > and/or provide ACLs to relevant other teams as needed. > > Robie > > On Mon, Dec 13, 2021 at 09:04:54AM -0800, Steve Langasek wrote: >> On Mon, Dec 13, 2021 at 07:31:16AM +0000, Robie Basak wrote: >>> On Sat, Dec 11, 2021 at 10:19:12AM -0800, Steve Langasek wrote: >>>> On Sat, Dec 11, 2021 at 08:00:23AM +0000, [email protected] wrote: >>>>> The following subscriptions are superfluous: >>>>> php8.1 >>>>> Superfluous subscriptions removed >>>> Please revert this, I subscribed the server team to php8.1 so it could be >>>> promoted and unblock php-defaults in -proposed. >>> Done. >>> Sorry this broke your workflow. We need any changes to our subscriptions >>> to be committed to git now[1]. I'm not sure how to make this less >>> painful for you next time, save for asking us instead of making the >>> change directly. >>> Any suggestions? >>> https://git.launchpad.net/~canonical-server/+git/team-subscriptions >> As I happen to be subscribed to ubuntu-server and see these emails, it's easy >> enough for me to follow up to confirm. I don't think all members of the >> Ubuntu Archive team are subscribed to this list, and I'm sure they're not >> aware there's been a Server Team-specific change to the promotion workflow. >> I'd suggest that you promulgate this to the Archive Team >> (ubuntu-release@lists) so that there's awareness and we can discuss how best >> to integrate this into the workflow. >> >> In the meantime I'd just ask that when your scripts detect a mismatch, the >> Server Team be proactive about following up to figure out why the mismatch >> was there. >> >> -- >> 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/ >> [email protected] [email protected] > > >> -- >> ubuntu-server mailing list >> [email protected] >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server >> More info: https://wiki.ubuntu.com/ServerTeam >
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
