Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions
Date: Sun, 09 Feb 2020 23:43:57
Message-Id: CAGfcS_m03RDHRcjxsu=LMo8-eMJQhU3sTUEK2Y1uM5qyrqzKSA@mail.gmail.com
In Reply to: Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions by Michael Jones
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

Replies