XPost: linux.debian.maint.boot, linux.debian.devel.release
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,
--
Cyril Brulebois (
kibi@debian.org) <
https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmQt458ACgkQ/5FK8MKz VSArdg//fev9FBvKQqioSZimrH9yLo4Ho+2WSWxrSmD4/w+tM9MFz0eAYOv88elT IXLD9dRdrZmdWq6gbZn/iILFXvDDOoKO2a/bIXduOTZLOzThi8mw1Ms1Vc4BDkCs dEakxrwQoqdcI/7sYEdAokhbuyb1wn10CB9bCZ5MyrE/NJlXOVBADFlp8U9t6/U7 wKwb3bgHNmtaTvl4fH+6n30kKkSWsGjXWH4Bc0do8HMqW8K5+p6uAHiatIKVFueS sWcowJaaGfi40mp707dq2+ZxO1CcJuA1li3gnKMnDRLm2KyovI1rCC59lcc76JFg j8VWOLC1tovmlHNrqoe8auSWqnD+Whv53tSLBQ9VckSvAgvKedHSlUk6nb3FTfxA QsHB0WI2HT7QtKZBK9F7+3WrSU0VnvhLnd6RPP245q53ZSBa2sMUtw0Sr33xjmUX ZECIer/HvT1IZ1qQIPDdcB9JQxdc3VFeX2HH+HzytPKtDiEz/Msz3gSczyL0Jwz7 J2CJmYi8sIeLF+uYtbhjBIk/IcHPCuQODnHFTGjaWml5+8fyA8mwhyjNfrHxSvw8 gvrU0hjdyJ5YJGVDQTHCrkYfW1ReokrP2YndRLYG/9pz8l8tvF5I2JUYoIOpO9Mt ZCLRWDbiA2j3jpvX8LzlQNlVk+TQsqZHB4MbVuP138QUTWrdIjY=
=Rvpd
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
*