Streamlining d-i releases

[Cyril Brulebois]

Hi ftp team,

As you know, publishing a Debian Installer release involves a bunch of
steps across various parts of the infrastructure, spanning across many
teams:
- debian-boot (many udebs + src:debian-installer upload)
- ftpmaster (dak copy-installer)
- debian-release (udebs + src:debian-installer migration)
- debian-cd (image builds)
- debian-www (debian.org/devel/debian-installer)

I'm able to prepare website updates via the webwml repository and to
trigger a partial rebuild of the website to publish the announce (via
an update-part sudo entry on wolkenstein).

Via debian-release I'm also able to hint (via unblock, unblock-udeb,
and urgent) udeb packages into testing, then block the migration of
udeb-producing packages for a few hours or days, which lets me upload
src:debian-installer on my own timing. I'm also able to hint it into
testing once it's built everywhere.

Since we have many moving parts, and since regressions or worries can
come up at any time, I don't think we would be able to come up with
some kind of schedule to coordinate with the ftp team, and I'm left
with having to poke you folks without advance warning. I really don't
like doing that, and depending on your availability, that might mean
several hours (all fine) or sometimes several days until the dak
copy-installer step happens. Once one factors in the other delays
(britney runs for package migration, dinstall runs to make changes
visible on mirrors, prior to the debian-installer upload, or after the
dak copy-installer step), this means the release process takes a very
while, including (sometimes very) long pauses


I'd like to see if we could shorten it by getting some extra autonomy,
to shorten the udeb freeze (it affects a bunch of packages that aren't
under the installer team's umbrella, and outside freeze stages it has
already upset people enough to trigger an argument during what was
supposed to be a nice evening at DebConf
) and to keep the release
energy and motivation as high as possible.

I realize that getting a sudo line on fasolo would mean increasing the
security risks quite a bunch for a limited gain. Since we already have
a mechanism to trigger changes in the archive via release team access,
that is /srv/release.debian.org/www/proposed-updates/*_comments (which
we can edit from coccia); maybe something similar could be done to
trigger dak copy-installer?


(The other side I usually entirely delegate is building images, and I
sync/resync with Steve along the way, based on whether d-i looks good
or whether I encounter and fix/workaround roadblocks, but I plan on
learning that on my own as well to avoid putting pressure on Steve
all the time — got the gid already, lacking know-how at the moment,
and possibly access to secrets for the ultimate signing.)


Cheers,

[Joerg Jaspert]

Post by Cyril Brulebois
I realize that getting a sudo line on fasolo would mean increasing the
security risks quite a bunch for a limited gain. Since we already have
a mechanism to trigger changes in the archive via release team access,
that is /srv/release.debian.org/www/proposed-updates/*_comments (which
we can edit from coccia); maybe something similar could be done to
trigger dak copy-installer?

I put SSH trigger into the room, instead of sudo. You supply the version
on the ssh cmdline, and if that exists in unstable, a copy-installer is
run with that version. Could even be extended to have source and target
suite selectable too.

[Cyril Brulebois]

Post by Joerg Jaspert

Post by Cyril Brulebois
I realize that getting a sudo line on fasolo would mean increasing the
security risks quite a bunch for a limited gain. Since we already have
a mechanism to trigger changes in the archive via release team access,
that is /srv/release.debian.org/www/proposed-updates/*_comments (which
we can edit from coccia); maybe something similar could be done to
trigger dak copy-installer?

I put SSH trigger into the room, instead of sudo. You supply the version
on the ssh cmdline, and if that exists in unstable, a copy-installer is
run with that version.

That looks very good to me, thanks!

Post by Joerg Jaspert
Could even be extended to have source and target suite selectable too.

I think we only released the installer via tpu once, at least that I
could confirm by checking my sent box:

dak copy-installer 20220917 -s bookworm-proposed-updates

but it could indeed be nice to be able to specify at least the source
suite, just in case we encounter some blocking bug in unstable again in
the future.


Cheers,

[Joerg Jaspert]

Post by Cyril Brulebois

Post by Joerg Jaspert
I put SSH trigger into the room, instead of sudo. You supply the version
on the ssh cmdline, and if that exists in unstable, a copy-installer is
run with that version.

That looks very good to me, thanks!

Post by Joerg Jaspert
Could even be extended to have source and target suite selectable too.

I think we only released the installer via tpu once, at least that I

I prepared a little script. Now need a SSH key to allow.
Usage is simple, you MUST supply a version, you CAN supply a source and
a dest suite. Space seperated.
It checks amd64s installer in that suite, and if the version directory
exists, it calls dak copy-installer on it.