On Sun, Feb 9, 2020 at 4:04 PM Michael Jones <gen...@jonesmz.com> wrote:
>
> On Fri, Feb 7, 2020 at 2:25 PM Rich Freeman <ri...@gentoo.org> wrote:
>>
>> On Fri, Feb 7, 2020 at 2:34 PM Michael Jones <gen...@jonesmz.com> wrote:
>> >
>> > 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.
>>
>
> But Rich, Linux-4.19.97 was released on Jan 17th, and then
> gentoo-sources-4.19.97 was released on Jan 18th, whereas
> https://bugs.gentoo.org/706036 was acknowledged to be fixed by
> Linux-4.19.99 on Jan 29th, and it's now Feb 9th and no newer
> gentoo-sources package has been stabilized.
>
> So we've got some inconsistency in how the gentoo-sources package is
> stabilized.

But, Michael, I really have no idea how what you said in any way
contradicts what I said...

Per the Gentoo kernel page they generally follow the 30 day policy
except for security issues.  My guess is that somebody thought 4.19.97
contained a security fix, and 4.19.99 did not.  The bug you linked
seemed to have nothing to do with security.  Pretty much EVERY kernel
release fixes bugs.

I get that you want stuff that personally affects you fixed faster,
and stuff that doesn't personally fixed you given careful examination
before release.  I don't see how you're going to get that without
doing your own QA.

> I'm not saying the current cadance isn't the right one, and i'm not
> saying it is. I'm just saying in this particular situation, it didn't
> fit one specific end-users needs, and maybe that's fine, and maybe
> it's not. I'm not the one putting in the work, so I'm not going to say
> the project *should* take an action. Just point out that there was a
> problem from my perspective.

Well, obviously I'm sympathetic.  If I thought that Gentoo's release
cadence fit my needs I'd be running Gentoo kernels.  :)

This topic has been discussed a few times but not recently that I am
aware of.  IMO they're doing better now than they were the last time I
actually used a Gentoo kernel (being mindful that the "they" likely
aren't the same people, and the better/worse part is subjective in any
case).

>> 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.
>
> That's 655 bugs with a last modified date of January 1st 2010 or older.
>
> And 2461 bugs with a last modified date between January 1st 2010 and Jan 1st 
> 2015.
>
> Please be aware that at least one person who uses and (minorly)
> contributes to Gentoo finds this off putting, bizarre, and incredibly
> difficult to interact with. It's intimidating to new users and old
> users of Bugzilla alike, and is a constant source of uncertainty and
> confusion on where to find something or if the bugzilla platform is
> actually even the right place to file an issue.

I'm sure lots of people find it bizarre.  I'm also sure that lots of
people would find doing what you propose bizarre also.  It is just a
matter of taste.  Granted, I think most people have bad taste, and
that most people would probably think I have bad taste, so there is
that.  :)

If you want to pretend that there aren't any bugs older than 10 years,
then just filter your searches and you won't see them.  Just pretend
they don't exist.  Problem solved.

>
> From my perspective, Bugzilla is where issues go to linger forever,
> because it's rare for me to see a bug opened there get any attention
> at all, such as being closed or commented on, much less transition to
> the confirmed state.

Bugs get closed all the time.  Bugs also get opened and and linger all
the time.  I couldn't tell you the ratio, but that is the nature of
things.

If you don't report an issue, and nobody else is aware of it, I can
pretty much guarantee that nobody will fix it.  If you do report an
issue it might or might not get fixed.  That's the nature of the
beast.

Honestly, I'm not sure how having bots beg bug reporters about letting
their bugs be closed relentlessly (albeit at a very slow rate) until
they finally stop responding is going to improve things.  Somebody
reports an issue and is frustrated that nobody does anything about it.
Will reminding them that we didn't do anything about it in 5-10 years
improve how they feel about the issue?  If they reply that it still is
an issue, will it help that we reply again in another 5 years to ask
if it is still an issue help?  It seems like picking at a scab when
the only people paying attention to a bug are the reporter and a bot.

My gut feeling is that this sort of thing will make people even less
likely to report new bugs they find, because they're constantly being
reminded of ancient situations where this turned out to be a waste of
time.  If they weren't reminded of this they'd be more likely to
report an issue, and that might or might not be a waste of time.

Obviously everybody would prefer that all bugs get fixed promptly.
Short of that, I'm not sure that automatically closing the bugs is an
improvement on what currently happens.  But, it probably wouldn't
personally offend me if old bugs were closed.  It just means that if
somebody does pick up that package and starts maintaining it again and
are cleaning things up, they might not fix some lingering issue that
they aren't aware of with it.

-- 
Rich

Reply via email to