On Fri, Feb 7, 2020 at 2:34 PM Michael Jones <gen...@jonesmz.com> wrote: > > Here's an example of how 4.19.97 being stabilized might have exposed users to > functionality breaking bugs: https://bugs.gentoo.org/706036 > > Honestly I'd rather see the 30 day stabilization policy apply to LTS kernels > vs. being stabilized faster. Maybe I'm once bitten twice shy.
One issue here is that the kernel upstream doesn't really consistently label kernels for bug criticality (including security bugs), or severity of regressions. So, in general any newer release should only make things better, but if a particular release made things much worse you'd only know from general discussion on high-volume lists. I follow upstream directly and just tend to hold off a day or two before updates, and look for signs of chatter before doing so. That is hardly optimal. A company like RedHat just hires a ton of kernel engineers to basically do their own QA on top of upstream's - they can stay on top of those sorts of problems. I'm sure the Gentoo kernel team does a better job than I personally do, but I doubt they can sink as much time as that. > As an aside: The gentoo bug tracker has way too many open bugs > (Thousands and thousands of them opened over 10 years ago), and the > search interface is... frustrating. Took me over 5 minutes to find > that bug despite being a commenter on it. Does anyone know if there's > any plans for that situation to change in any way? I doubt it, but the search interface is probably more likely to change than the number of open bugs. I mean, you could just close bugs without resolving them after a period of time. That would make the open bug counts look better, but it wouldn't change the actual quality of the distro, and would just tend to hide problems packages that are still in the repo. Obviously fixing bugs would be the ideal path, but we're volunteer driven, so that is up to the volunteers. I mean, we could just remove any package from the repo that has open bugs older than a certain time, but that seems likely to just end up with a repo without any packages in it. Unless the bugs have security implications or are causing impact to updates to other packages there usually isn't any policy requiring that they be fixed. I'm sure lots of people would be up for improving the UI, though that still requires volunteer work. Also, if the fix involves switching away from bugzilla that is a much bigger hurdle, and one challenge is that Gentoo doesn't like to host stuff written in Java/Ruby, which tends to exclude a lot of popular stuff. I don't sysadmin webservers for a living, so I won't comment on whether that policy is a good one or a bad one, but I suspect those behind it know a lot more about maintaining webservers than I do... -- Rich
