| 1 |
On Fri, Feb 7, 2020 at 2:34 PM Michael Jones <gentoo@×××××××.com> wrote: |
| 2 |
> |
| 3 |
> Here's an example of how 4.19.97 being stabilized might have exposed users to functionality breaking bugs: https://bugs.gentoo.org/706036 |
| 4 |
> |
| 5 |
> 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. |
| 6 |
|
| 7 |
One issue here is that the kernel upstream doesn't really consistently |
| 8 |
label kernels for bug criticality (including security bugs), or |
| 9 |
severity of regressions. |
| 10 |
|
| 11 |
So, in general any newer release should only make things better, but |
| 12 |
if a particular release made things much worse you'd only know from |
| 13 |
general discussion on high-volume lists. |
| 14 |
|
| 15 |
I follow upstream directly and just tend to hold off a day or two |
| 16 |
before updates, and look for signs of chatter before doing so. That |
| 17 |
is hardly optimal. |
| 18 |
|
| 19 |
A company like RedHat just hires a ton of kernel engineers to |
| 20 |
basically do their own QA on top of upstream's - they can stay on top |
| 21 |
of those sorts of problems. I'm sure the Gentoo kernel team does a |
| 22 |
better job than I personally do, but I doubt they can sink as much |
| 23 |
time as that. |
| 24 |
|
| 25 |
> As an aside: The gentoo bug tracker has way too many open bugs |
| 26 |
> (Thousands and thousands of them opened over 10 years ago), and the |
| 27 |
> search interface is... frustrating. Took me over 5 minutes to find |
| 28 |
> that bug despite being a commenter on it. Does anyone know if there's |
| 29 |
> any plans for that situation to change in any way? |
| 30 |
|
| 31 |
I doubt it, but the search interface is probably more likely to change |
| 32 |
than the number of open bugs. |
| 33 |
|
| 34 |
I mean, you could just close bugs without resolving them after a |
| 35 |
period of time. That would make the open bug counts look better, but |
| 36 |
it wouldn't change the actual quality of the distro, and would just |
| 37 |
tend to hide problems packages that are still in the repo. Obviously |
| 38 |
fixing bugs would be the ideal path, but we're volunteer driven, so |
| 39 |
that is up to the volunteers. I mean, we could just remove any |
| 40 |
package from the repo that has open bugs older than a certain time, |
| 41 |
but that seems likely to just end up with a repo without any packages |
| 42 |
in it. Unless the bugs have security implications or are causing |
| 43 |
impact to updates to other packages there usually isn't any policy |
| 44 |
requiring that they be fixed. |
| 45 |
|
| 46 |
I'm sure lots of people would be up for improving the UI, though that |
| 47 |
still requires volunteer work. Also, if the fix involves switching |
| 48 |
away from bugzilla that is a much bigger hurdle, and one challenge is |
| 49 |
that Gentoo doesn't like to host stuff written in Java/Ruby, which |
| 50 |
tends to exclude a lot of popular stuff. I don't sysadmin webservers |
| 51 |
for a living, so I won't comment on whether that policy is a good one |
| 52 |
or a bad one, but I suspect those behind it know a lot more about |
| 53 |
maintaining webservers than I do... |
| 54 |
|
| 55 |
-- |
| 56 |
Rich |
Archives