Hi, Raphaël Halimi <raphael.halimi@gmail.com> (2019-07-01): > Le 29/06/2019 à 16:20, Cyril Brulebois a écrit : > > Plus, we've got a MR against apt-setup now, see #851774. It's also > > come late and nobody reviewed it yet. Plus, the other, serious bug > > report was marked as buster-ignore by a release team member, so > > there's no *need* to fix this before buster. > > What exactly does "MR" mean ? I googled but I didn't find anything. > > > All in all, it looks like we're instead going to consider the MR at the > > beginning of the bullseye release cycle, and backport the fix to buster > > if it proves to be working fine. > > That's where I disagree. More precisely, I don't understand how the > current situation (which is that generators/60local crashes > systematically, unless in the very rare case that an unsigned > repository is configured, **and** > debian-installer/allow_unauthenticated is set) can be preferable to > merging the patch in [1] before release. > > (There was also a merge request based on this patch [2] which didn't > receive any answer) Merge request, MR. So you're pointing out exactly what I was referring to. > Please enlighten me (I'm not being ironic here, this is a legitimate > question, I really don't understand how releasing Buster with a partly > broken apt-setup is preferable to merging a patch which is admittedly > not tested by a lot of people, but is so simple that it's very > unlikely to fail, especially when 60local nearly **always** fail > without a fix). Because it makes no sense to be making changes until the very last minute. Especially for a highly specific use case where one would expect advanced users to be able to find the relevant bug report(s). > Personally, I don't mind, since my PXE server has a complex preseed > system with preseed file snippets, scripts and hooks everywhere, so > adding a hook to replace 60local for Buster was very easy; but I'm > thinking of people who use a single preseed file, they will have a > really bad surprise when Buster is released. If you personally don't mind, you may want to just trust us to make the right call. Hypothetical users that haven't been testing release candidates and haven't noticed the issue can surely 1) find bug reports when they run into this issue; 2) apply a workaround; 3) or wait until 10.1 is released. > If you don't change your mind, please at least agree that this bug > (and its possible workarounds) must absolutely be documented with big > fat warnings in the preseed documentation [3]. An errata item might be in order; but then, we tend to put out .1 rather quickly so that might mean more work for translators for little benefits anyway. > I have to say that I **really** miss the times when a new Debian > release was ready "when it's ready"... :( I'll refrain from adding my own “I have to say” here. Cheers anyway, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature