1 |
On Sun, Feb 9, 2020 at 4:04 PM Michael Jones <gentoo@×××××××.com> wrote: |
2 |
> |
3 |
> On Fri, Feb 7, 2020 at 2:25 PM Rich Freeman <rich0@g.o> wrote: |
4 |
>> |
5 |
>> On Fri, Feb 7, 2020 at 2:34 PM Michael Jones <gentoo@×××××××.com> wrote: |
6 |
>> > |
7 |
>> > 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. |
8 |
>> |
9 |
>> One issue here is that the kernel upstream doesn't really consistently |
10 |
>> label kernels for bug criticality (including security bugs), or |
11 |
>> severity of regressions. |
12 |
>> |
13 |
> |
14 |
> But Rich, Linux-4.19.97 was released on Jan 17th, and then |
15 |
> gentoo-sources-4.19.97 was released on Jan 18th, whereas |
16 |
> https://bugs.gentoo.org/706036 was acknowledged to be fixed by |
17 |
> Linux-4.19.99 on Jan 29th, and it's now Feb 9th and no newer |
18 |
> gentoo-sources package has been stabilized. |
19 |
> |
20 |
> So we've got some inconsistency in how the gentoo-sources package is |
21 |
> stabilized. |
22 |
|
23 |
But, Michael, I really have no idea how what you said in any way |
24 |
contradicts what I said... |
25 |
|
26 |
Per the Gentoo kernel page they generally follow the 30 day policy |
27 |
except for security issues. My guess is that somebody thought 4.19.97 |
28 |
contained a security fix, and 4.19.99 did not. The bug you linked |
29 |
seemed to have nothing to do with security. Pretty much EVERY kernel |
30 |
release fixes bugs. |
31 |
|
32 |
I get that you want stuff that personally affects you fixed faster, |
33 |
and stuff that doesn't personally fixed you given careful examination |
34 |
before release. I don't see how you're going to get that without |
35 |
doing your own QA. |
36 |
|
37 |
> I'm not saying the current cadance isn't the right one, and i'm not |
38 |
> saying it is. I'm just saying in this particular situation, it didn't |
39 |
> fit one specific end-users needs, and maybe that's fine, and maybe |
40 |
> it's not. I'm not the one putting in the work, so I'm not going to say |
41 |
> the project *should* take an action. Just point out that there was a |
42 |
> problem from my perspective. |
43 |
|
44 |
Well, obviously I'm sympathetic. If I thought that Gentoo's release |
45 |
cadence fit my needs I'd be running Gentoo kernels. :) |
46 |
|
47 |
This topic has been discussed a few times but not recently that I am |
48 |
aware of. IMO they're doing better now than they were the last time I |
49 |
actually used a Gentoo kernel (being mindful that the "they" likely |
50 |
aren't the same people, and the better/worse part is subjective in any |
51 |
case). |
52 |
|
53 |
>> I mean, you could just close bugs without resolving them after a |
54 |
>> period of time. That would make the open bug counts look better, but |
55 |
>> it wouldn't change the actual quality of the distro, and would just |
56 |
>> tend to hide problems packages that are still in the repo. |
57 |
> |
58 |
> That's 655 bugs with a last modified date of January 1st 2010 or older. |
59 |
> |
60 |
> And 2461 bugs with a last modified date between January 1st 2010 and Jan 1st 2015. |
61 |
> |
62 |
> Please be aware that at least one person who uses and (minorly) |
63 |
> contributes to Gentoo finds this off putting, bizarre, and incredibly |
64 |
> difficult to interact with. It's intimidating to new users and old |
65 |
> users of Bugzilla alike, and is a constant source of uncertainty and |
66 |
> confusion on where to find something or if the bugzilla platform is |
67 |
> actually even the right place to file an issue. |
68 |
|
69 |
I'm sure lots of people find it bizarre. I'm also sure that lots of |
70 |
people would find doing what you propose bizarre also. It is just a |
71 |
matter of taste. Granted, I think most people have bad taste, and |
72 |
that most people would probably think I have bad taste, so there is |
73 |
that. :) |
74 |
|
75 |
If you want to pretend that there aren't any bugs older than 10 years, |
76 |
then just filter your searches and you won't see them. Just pretend |
77 |
they don't exist. Problem solved. |
78 |
|
79 |
> |
80 |
> From my perspective, Bugzilla is where issues go to linger forever, |
81 |
> because it's rare for me to see a bug opened there get any attention |
82 |
> at all, such as being closed or commented on, much less transition to |
83 |
> the confirmed state. |
84 |
|
85 |
Bugs get closed all the time. Bugs also get opened and and linger all |
86 |
the time. I couldn't tell you the ratio, but that is the nature of |
87 |
things. |
88 |
|
89 |
If you don't report an issue, and nobody else is aware of it, I can |
90 |
pretty much guarantee that nobody will fix it. If you do report an |
91 |
issue it might or might not get fixed. That's the nature of the |
92 |
beast. |
93 |
|
94 |
Honestly, I'm not sure how having bots beg bug reporters about letting |
95 |
their bugs be closed relentlessly (albeit at a very slow rate) until |
96 |
they finally stop responding is going to improve things. Somebody |
97 |
reports an issue and is frustrated that nobody does anything about it. |
98 |
Will reminding them that we didn't do anything about it in 5-10 years |
99 |
improve how they feel about the issue? If they reply that it still is |
100 |
an issue, will it help that we reply again in another 5 years to ask |
101 |
if it is still an issue help? It seems like picking at a scab when |
102 |
the only people paying attention to a bug are the reporter and a bot. |
103 |
|
104 |
My gut feeling is that this sort of thing will make people even less |
105 |
likely to report new bugs they find, because they're constantly being |
106 |
reminded of ancient situations where this turned out to be a waste of |
107 |
time. If they weren't reminded of this they'd be more likely to |
108 |
report an issue, and that might or might not be a waste of time. |
109 |
|
110 |
Obviously everybody would prefer that all bugs get fixed promptly. |
111 |
Short of that, I'm not sure that automatically closing the bugs is an |
112 |
improvement on what currently happens. But, it probably wouldn't |
113 |
personally offend me if old bugs were closed. It just means that if |
114 |
somebody does pick up that package and starts maintaining it again and |
115 |
are cleaning things up, they might not fix some lingering issue that |
116 |
they aren't aware of with it. |
117 |
|
118 |
-- |
119 |
Rich |