Re: Should a serious bug have made in into bullseye 11.5?
On Mon 12 Sep 2022 at 14:20:59 (+0100), Tim Woodall wrote:
> On Mon, 12 Sep 2022, Andy Smith wrote:
> > On Mon, Sep 12, 2022 at 12:00:20PM +0000, Andy Smith wrote:
> > > Obviously, no one desires for there to be bugs, so your question
> > > doesn't really make sense. "Should bugs make it into Debian releases"?
> >
> > Ah, sorry, I think I misunderstood - you are literally asking if the
> > presence of a severity "serious" bug in Grub should have prevented
> > the whole 11.5 point release happening?
> >
> > I don't know. The only documentation I can find on the matter is
> > about full Debian releases and even that says the bugs would have to
> > be apmrked "release-critical" (RC) to block release, so not even
> > "critical" may have postponed things.
> >
> Interesting. I didn't find this bug report until after I'd already
> tracked down the culprit package and was ready to file my own bug.
Presumably apt-listbugs would have spotted this as the bug was raised
to serious last Tuesday, and the point-release was days after that.
> > My gut feeling is that there's going to be quite a lot of
> > "serious"-level bugs in any point release and that no one works to
> > associate these with a recent upload and then prevent that going
> > into a new point release.
> >
> > It still feels more useful to focus on how such problems can be
> > avoided in future. I don't think we can explore the release team
> > looking at every "serious" bug in every package otherwise they'd
> > never get a point release out.
Well, my focus would be on two things: (a) the change in compatibility
level in debhelper in the middle of stable's lifetime, and (b) on why
grub-xen-host has fallen behind on the debhelper compatibility level
that it supports. I don't know enought to comment on (a).
It would seem to be a simple matter for g-x-h to have used the
exception mechanism in debhelper rather than to rely on its
guesswork. But I also guess that it would be easy to miss the change
when it occurred (2017) because xen in this configuration is
relatively little used and therefore less resourced.
But if g-x-h had raised the compatibility level in a more timely
manner, then I think this bug would have had to escape notice for
~two years in bullseye-as-testing, rather than the two months in
bookworm/testing in order to survive in stable. This bug illustrates
the danger of sticking with an ancient compatibility level.
> Agreed. While I tend to try to file bugs at the lowest severity that can
> be justified, I know that others go the other way. This is one I'd
> probably have filed as Grave or even Critical. (I see it's now been
> bumped to Grave)
>
> It just felt wrong to me that this bug (and version bump of the
> package) could go to stable without someone at least acknowleging the
> bug. AFAICT there's no fundamental reason it needed to go out.
Perhaps because this version of Grub fixes seven CVEs?
> If it was
> that the reporter should have marked it grave or critical then fair
> enough, just unfortunate that they didn't.
The reporter is often not best-placed to make that judgment.
> The same version also went to oldstable - where it turns out it works
> fine - so I can see how it could be missed but this was a bug that I
> feel would have, if necessary, justified delaying the 11.5 release and I
> wonder what a bug reporter should do in a case like this.
AFAICT it had two months in testing without this problem being
hit and reported.
> Fortunately, from my PoV, it came with a kernel update and at the
> weekend, so I rebooted and had time to investigate what was going on.
> Otherwise I might have been blissfully unaware until a power-cut...
>
> Unfortunately, on Saturday morning I'd removed pvshim=1 from the last of
> my guests and restarted them (successfully) so I wasn't 100% sure it
> wasn't something I'd done wrong.
I notice that others are now suggesting apt-listbugs. I've seen real
show-stoppers in its reports on occasions, but they've usually not
applied to my systems (different architectures, or combination of
packages etc), determined by inspecting the already downloaded package.
A real boon though.
Cheers,
David.
Reply to: