Hi Salvatore, Salvatore Bonaccorso <car...@debian.org> (2021-08-06): > When installing bullseye with the current RC3 I noticed that while the > debconf menu suggests (and has selected) to add release updates suites > ($codename-updates) to the sources.list in case when bullseye is yet > testing, they are not added via generators/92updates because > generators/90services-select in case of the suite not beeng stable or > odstable, does not select it: > > updates=y > if [ "$suite" != stable ] && [ "$suite" != oldstable ]; then > disable_service updates || true > updates=n > fi
Sorry we dropped the ball here, and only recently discovered it again… > I wonder if this could be handled in times before a stable release is > planned, and the suite is already present on the mirrors (this is at > some time before a stable release prepartion when release team starts to > interact with infrastructure teams I think to setup what is needed for > the next stable release) > > The reason I ask this, is that the coverage would be bigger for people > having it in the sources.list if they install it in time shortly before > a stable release is released, and we strongly rely on updates to be > possible to push via the stable-updates mechanism, see for instance > https://lists.debian.org/debian-stable-announce/2021/06/msg00001.html ? > > Cyril mentioned two ideas how this can be done. Either having a flag > which can be enabled one we switch from an Alpha to some RC Release for > d-i once the installer matured enough and infrastructure is set up in > perspective of a future stable release. > > One other alternative would be to do an online test if the suite is > already present and only add it in that case. Unless it's a particular burden, I think it would make sense to have -updates enabled during the entirety of the “testing” release cycle. There might be people that use an Alpha release (for whatever reason) and end up not reinstalling with an RC or a final release, and those would lack those entries. I've asked my release team fellows regarding when the suite is created (on release date or later on), but I anticipate two possible outcomes: - It's present from day 0, and we're done here. - It's not present on day 0, and we notice it's missing when testing the installer, be it via daily builds, or when zero-ing in on Alpha 1, at which point we are reminded of asking for its creation; and/or we disable -updates for testing again, for some time. [Edit right before sending: zeha verified that both directories under dists/ appeared on release day, so we should be in the latter case.] This way, we get predictable results, instead of relying on a one-time detection (a single request might fail for various reasons). I'm happy to listen to other opinions, of course. > What do you think of this idea? If you think it's nonsense, feel free > to mark it straight as wontfix and close it. That's definitely a very interesting report, not at all nonsense. Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
