1 |
On Fri, Feb 7, 2020 at 2:25 PM Rich Freeman <rich0@g.o> wrote: |
2 |
|
3 |
> On Fri, Feb 7, 2020 at 2:34 PM Michael Jones <gentoo@×××××××.com> wrote: |
4 |
> > |
5 |
> > Here's an example of how 4.19.97 being stabilized might have exposed |
6 |
> users to functionality breaking bugs: https://bugs.gent was released on |
7 |
> Jan 18thoo.org/706036 <https://bugs.gentoo.org/706036> |
8 |
> > |
9 |
> > Honestly I'd rather see the 30 day stabilization policy apply to LTS |
10 |
> kernels vs. being stabilized faster. Maybe I'm once bitten twice shy. |
11 |
> |
12 |
> One issue here is that the kernel upstream doesn't really consistently |
13 |
> label kernels for bug criticality (including security bugs), or |
14 |
> severity of regressions. |
15 |
> |
16 |
> So, in general any newer release should only make things better, but |
17 |
> if a particular release made things much worse you'd only know from |
18 |
> general discussion on high-volume lists. |
19 |
> |
20 |
> I follow upstream directly and just tend to hold off a day or two |
21 |
> before updates, and look for signs of chatter before doing so. That |
22 |
> is hardly optimal. |
23 |
> |
24 |
> A company like RedHat just hires a ton of kernel engineers to |
25 |
> basically do their own QA on top of upstream's - they can stay on top |
26 |
> of those sorts of problems. I'm sure the Gentoo kernel team does a |
27 |
> better job than I personally do, but I doubt they can sink as much |
28 |
> time as that. |
29 |
> |
30 |
> |
31 |
Again, no animosity against anyone: |
32 |
|
33 |
But Rich, Linux-4.19.97 was released on Jan 17th, and then |
34 |
gentoo-sources-4.19.97 was released on Jan 18th, whereas |
35 |
https://bugs.gentoo.org/706036 was acknowledged to be fixed by |
36 |
Linux-4.19.99 on Jan 29th, and it's now Feb 9th and no newer gentoo-sources |
37 |
package has been stabilized. |
38 |
|
39 |
So we've got some inconsistency in how the gentoo-sources package is |
40 |
stabilized. You don't mind going directly with the upstream package, but I |
41 |
personally do, which is why I used the gentoo-sources package for my kernel |
42 |
needs in large part because I have trust in the Gentoo distribution to |
43 |
provide that small but crucial extra layer of insider knowledge on how |
44 |
likely a particular upstream kernel release is going to break my systems. |
45 |
|
46 |
I certainly don't have a relationship with Gentoo where I pay money to |
47 |
someone and expect some kind of service level guarantees, so honestly this |
48 |
email is just a lot of hot-air. But if Gentoo wants to provide good |
49 |
experiences to end users who are updating their kernels, I personally think |
50 |
it's worth considering the release cadance and whether the currently used |
51 |
one is the right fit for the actual goals of the project. |
52 |
|
53 |
I'm not saying the current cadance isn't the right one, and i'm not saying |
54 |
it is. I'm just saying in this particular situation, it didn't fit one |
55 |
specific end-users needs, and maybe that's fine, and maybe it's not. I'm |
56 |
not the one putting in the work, so I'm not going to say the project |
57 |
*should* take an action. Just point out that there was a problem from my |
58 |
perspective. |
59 |
|
60 |
|
61 |
|
62 |
> > As an aside: The gentoo bug tracker has way too many open bugs |
63 |
> > (Thousands and thousands of them opened over 10 years ago), and the |
64 |
> > search interface is... frustrating. Took me over 5 minutes to find |
65 |
> > that bug despite being a commenter on it. Does anyone know if there's |
66 |
> > any plans for that situation to change in any way? |
67 |
> |
68 |
> I doubt it, but the search interface is probably more likely to change |
69 |
> than the number of open bugs. |
70 |
> |
71 |
> I mean, you could just close bugs without resolving them after a |
72 |
> period of time. That would make the open bug counts look better, but |
73 |
> it wouldn't change the actual quality of the distro, and would just |
74 |
> tend to hide problems packages that are still in the repo. Obviously |
75 |
> fixing bugs would be the ideal path, but we're volunteer driven, so |
76 |
> that is up to the volunteers. I mean, we could just remove any |
77 |
> package from the repo that has open bugs older than a certain time, |
78 |
> but that seems likely to just end up with a repo without any packages |
79 |
> in it. Unless the bugs have security implications or are causing |
80 |
> impact to updates to other packages there usually isn't any policy |
81 |
> requiring that they be fixed. |
82 |
> |
83 |
> I'm sure lots of people would be up for improving the UI, though that |
84 |
> still requires volunteer work. Also, if the fix involves switching |
85 |
> away from bugzilla that is a much bigger hurdle, and one challenge is |
86 |
> that Gentoo doesn't like to host stuff written in Java/Ruby, which |
87 |
> tends to exclude a lot of popular stuff. I don't sysadmin webservers |
88 |
> for a living, so I won't comment on whether that policy is a good one |
89 |
> or a bad one, but I suspect those behind it know a lot more about |
90 |
> maintaining webservers than I do... |
91 |
> |
92 |
> -- |
93 |
> Rich |
94 |
> |
95 |
> |
96 |
https://bugs.gentoo.org/buglist.cgi?limit=0&order=changed |
97 |
<https://bugs.gentoo.org/buglist.cgi?limit=0&order=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Gentoo%20Linux&query_format=advanced&resolution=---> |
98 |
|
99 |
Apparently better than it used to be. The last time I surveyed bugzilla it |
100 |
date%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Gentoo%20Linux&query_format=advanced&resolution=--- |
101 |
<https://bugs.gentoo.org/buglist.cgi?limit=0&order=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Gentoo%20Linux&query_format=advanced&resolution=---> |
102 |
|
103 |
That's 655 bugs with a last modified date of January 1st 2010 or older. |
104 |
|
105 |
And 2461 bugs with a last modified date between January 1st 2010 and Jan |
106 |
1st 2015. |
107 |
|
108 |
Bugzilla actually only reports a max of 10,000 open bugs with that search. |
109 |
Which stops at Dec 28th, 2018. |
110 |
|
111 |
Please be aware that at least one person who uses and (minorly) contributes |
112 |
to Gentoo finds this off putting, bizarre, and incredibly difficult to |
113 |
interact with. It's intimidating to new users and old users of Bugzilla |
114 |
alike, and is a constant source of uncertainty and confusion on where to |
115 |
find something or if the bugzilla platform is actually even the right place |
116 |
to file an issue. |
117 |
|
118 |
From my perspective, Bugzilla is where issues go to linger forever, because |
119 |
it's rare for me to see a bug opened there get any attention at all, such |
120 |
as being closed or commented on, much less transition to the confirmed |
121 |
state. |
122 |
|
123 |
If you're honestly fine with this situation, so be it. However, I really do |
124 |
think Gentoo would be better overall if bugs were automatically closed if |
125 |
the last activity was 10 years ago, and bugs automatically commented on by |
126 |
a bot asking the reporter if the issue is still an issue if the last |
127 |
activity was 5 years ago. |
128 |
|
129 |
Surely if a bug is open for 10 years without any human interaction at all, |
130 |
it can't have really been that much of a problem to begin with? |