Re: missing unblock requests (was Re: bullseye release planned on 2021-08-14 and the last weeks up to the release)
Holger Levsen writes: > On Sat, Jul 24, 2021 at 09:36:15PM +0200, Ole Streicher wrote: >> I already had the situation that I accidently uploaded to sid instead of >> experimental, and I then created an RC bug to block migration. Frequent >> reminders about the non-migration wouldn't have helped me to solve the >> problem. > > you mean like this: > >1 s Jul 23 Paul Gevers (3.3K) bullseye release planned on > 2021-08-14 and the last weeks up to the release >2 s Jul 17 Paul Gevers (1.4K) Debian bullseye fully frozen >7 S Jun 14 Cyril Brulebois (4.7K) Debian Installer Bullseye RC 2 > release >8 s Jun 13 Paul Gevers (1.3K) Full Freeze starts on 2021-07-17 > 12 s May 02 Paul Gevers (4.4K) bits from the Release Team: > bullseye status update > 13 S Apr 23 Cyril Brulebois (6.3K) Debian Installer Bullseye RC 1 > release > 26 s Mar 20 Paul Gevers (2.2K) Bits from the Release Team: > frozen hard to get hot > > ? No, I meant the mails that were proposed to be sent out periodically for packages that don't migrate for one or the other reason. My point here is: mistakes do happen, also in the upload to unstable. And a common way to work around an unwanted upload is a blocking RC bug to prevent migration. Sometimes, this even happens after an intended upload, f.e. when the maintainer considers a package to be not ready at all for the next release. Virtualbox is such a never migrating package. Long migration times are definitely something one should have a look, but they are not a general reason to put pressure on the maintainer. Cheers Ole
Re: missing unblock requests (was Re: bullseye release planned on 2021-08-14 and the last weeks up to the release)
On Sat, Jul 24, 2021 at 09:36:15PM +0200, Ole Streicher wrote: > I already had the situation that I accidently uploaded to sid instead of > experimental, and I then created an RC bug to block migration. Frequent > reminders about the non-migration wouldn't have helped me to solve the > problem. you mean like this: 1 s Jul 23 Paul Gevers (3.3K) bullseye release planned on 2021-08-14 and the last weeks up to the release 2 s Jul 17 Paul Gevers (1.4K) Debian bullseye fully frozen 7 S Jun 14 Cyril Brulebois (4.7K) Debian Installer Bullseye RC 2 release 8 s Jun 13 Paul Gevers (1.3K) Full Freeze starts on 2021-07-17 12 s May 02 Paul Gevers (4.4K) bits from the Release Team: bullseye status update 13 S Apr 23 Cyril Brulebois (6.3K) Debian Installer Bullseye RC 1 release 26 s Mar 20 Paul Gevers (2.2K) Bits from the Release Team: frozen hard to get hot ? you might want to subscribe to https://lists.debian.org/debian-devel-announce/ and read those mails... and if in doubt, just go to https://release.debian.org/ - this page is really nicely structured and updated frequently, and has information directly from the source! :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ We live in a world where teenagers get more and more desperate trying to convince adults to behave like grown ups. signature.asc Description: PGP signature
Re: missing unblock requests (was Re: bullseye release planned on 2021-08-14 and the last weeks up to the release)
Thorsten Glaser writes: > Actually… it might be useful if there was a tool to do that and > ping the maintainers every three days or so during the entire > freeze (including early). The annoyance of those mails might even > serve to help making maintainers avoid uploads to sid that they > don’t want to include in the release during the freeze… I know > that each time there are *way* too many of those… I already had the situation that I accidently uploaded to sid instead of experimental, and I then created an RC bug to block migration. Frequent reminders about the non-migration wouldn't have helped me to solve the problem. Cheers Ole
Re: missing unblock requests (was Re: bullseye release planned on 2021-08-14 and the last weeks up to the release)
Hi Thorsten, On 24-07-2021 00:21, Thorsten Glaser wrote: > Might be useful to script-check everything that’s newer in sid > than in testing against the open unblock requests. > I have seen > changes that are definitely targetting bullseye (RC bug python > 2 removal, in fritzing-parts, for example) where the maintainer > seems to have forgotten them (same for occasional post-NMU up‐ > loads and even binNMUs), as well as uploads for packages where > I thought they’d have unblock requests and am surprised to see > none (bash, for example). Things that we probably want to have > in the release and that went below the radar for weeks? Since mid 2020 I have been filing out-of-sync bugs [0] with a script of mine [1]. Without the check that you suggest about unblock bugs, it reports 365 packages being out-of-sync longer than 60 days. The total list is longer and not reviewable by the Release Team. The number of unblock bugs is 17. The number of blocked RC bug fixes is 7. > Actually… it might be useful if there was a tool to do that and > ping the maintainers every three days or so during the entire > freeze (including early). The annoyance of those mails might even > serve to help making maintainers avoid uploads to sid that they > don’t want to include in the release during the freeze… I know > that each time there are *way* too many of those… Sure, maybe next release. As always, patches welcome. Paul [0] I stopped after the soft freeze for hopefully obvious reasons [1] based on udd (if I copy/pasted correctly): psql service=udd -c 'select source, testing_version, unstable_version, sync from migrations where in_testing = date(now()) and date(sync) < date(now()) - 60 ;' OpenPGP_signature Description: OpenPGP digital signature
missing unblock requests (was Re: bullseye release planned on 2021-08-14 and the last weeks up to the release)
Paul Gevers dixit: > > * **Unblock request** deadline: > 2021-08-03 12:00 UTC < > > - You must submit your unblock request *before* then > - Your changes must be ready to migrate to bullseye at that time > - Upload several days *before* the deadline Might be useful to script-check everything that’s newer in sid than in testing against the open unblock requests. I have seen changes that are definitely targetting bullseye (RC bug python 2 removal, in fritzing-parts, for example) where the maintainer seems to have forgotten them (same for occasional post-NMU up‐ loads and even binNMUs), as well as uploads for packages where I thought they’d have unblock requests and am surprised to see none (bash, for example). Things that we probably want to have in the release and that went below the radar for weeks? Actually… it might be useful if there was a tool to do that and ping the maintainers every three days or so during the entire freeze (including early). The annoyance of those mails might even serve to help making maintainers avoid uploads to sid that they don’t want to include in the release during the freeze… I know that each time there are *way* too many of those… bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
