Question about gentoo-sources kernel release versions

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Question about gentoo-sources kernel release versions

Matt Connell
I see posts on LWN (or other sources) for kernel minor version releases,
such as this one: https://lwn.net/Articles/811334/  The notes will
typically say that users should upgrade to that minor version due to bug
fixes or security patches.

I know that gentoo-sources tracks on the most current LTS kernel
release, currently 4.19.97.  However, these versions seem to usually be
slightly behind the 'recommended' minor version number.

Why is this?  Is it because the Gentoo patchset precludes the issues
that are being resolved by the LTS releases?  Are the issues considered
significantly minor enough that they don't warrant a version bump for
gentoo-sources?

No complaint or dissatisfaction being expressed here, just curious why
this seems to be, and if I should consider accepting ~amd64 for a newer
version.


Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Ian Zimmerman-3
On 2020-02-05 22:14, Matt Connell wrote:

> I know that gentoo-sources tracks on the most current LTS kernel
> release, currently 4.19.97.  

5.4 has just become the newest LTS.

--
Ian

Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Matt Connell
On 2020-02-06 11:40, Ian Zimmerman wrote:
> 5.4 has just become the newest LTS.

I see that now.  But my original question still stands as to why the
stable version of gentoo-sources is consistently a few versions behind
the latest LTS release.

Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Franz Fellner
In reply to this post by Matt Connell
That article you linked to is about a variant of linux, "rt". And as it looks they didn't update their branch since the release of 4.19.100-r41.
linux is at 4.19.102 now...

AFAIR the Gentoo kernel team knows what's going on regarding upcoming linux patches.
They know about the fixes in each minor release. And they kinda sort out what's important enough and what not.
Because longterm gets releases every few DAYS (!) and forcing the user to update the kernel after every single sync is hardcore.

IMO it's good the way it is.

Am Do., 6. Feb. 2020 um 06:14 Uhr schrieb Matt Connell <[hidden email]>:
I see posts on LWN (or other sources) for kernel minor version releases,
such as this one: https://lwn.net/Articles/811334/  The notes will
typically say that users should upgrade to that minor version due to bug
fixes or security patches.

I know that gentoo-sources tracks on the most current LTS kernel
release, currently 4.19.97.  However, these versions seem to usually be
slightly behind the 'recommended' minor version number.

Why is this?  Is it because the Gentoo patchset precludes the issues
that are being resolved by the LTS releases?  Are the issues considered
significantly minor enough that they don't warrant a version bump for
gentoo-sources?

No complaint or dissatisfaction being expressed here, just curious why
this seems to be, and if I should consider accepting ~amd64 for a newer
version.


Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Arve Barsnes
On Fri, 7 Feb 2020 at 06:19, Franz Fellner <[hidden email]> wrote:
>
> That article you linked to is about a variant of linux, "rt". And as it looks they didn't update their branch since the release of 4.19.100-r41.
> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.19-rt
> linux is at 4.19.102 now...

Just a note: that is a kind of "LTS" branch of the RT-kernels, the
current one is 5.4.17-rt9

Regards,
Arve

Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Mike Gilbert-2
In reply to this post by Matt Connell
On Thu, Feb 6, 2020 at 10:23 PM Matt Connell <[hidden email]> wrote:
>
> On 2020-02-06 11:40, Ian Zimmerman wrote:
> > 5.4 has just become the newest LTS.
>
> I see that now.  But my original question still stands as to why the
> stable version of gentoo-sources is consistently a few versions behind
> the latest LTS release.

Typically, Gentoo maintainers leave new versions in ~arch for some
time so they can be tested by a broad set of people. Stabilization
bugs are normally not filed until a given version has spent at least
30 days in ~arch.

See GLEP 40 for details on this process.

https://www.gentoo.org/glep/glep-0040.html

Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Franz Fellner
That doesn't apply to the kernel.
4.19.97 got tagged on January 17.
January 18. it was stable on amd64 and x86 - one day instead of 30.
Here is the stabilization request: https://bugs.gentoo.org/705006
There were some issues and changes to the targeted versions.


Am Fr., 7. Feb. 2020 um 19:18 Uhr schrieb Mike Gilbert <[hidden email]>:
On Thu, Feb 6, 2020 at 10:23 PM Matt Connell <[hidden email]> wrote:
>
> On 2020-02-06 11:40, Ian Zimmerman wrote:
> > 5.4 has just become the newest LTS.
>
> I see that now.  But my original question still stands as to why the
> stable version of gentoo-sources is consistently a few versions behind
> the latest LTS release.

Typically, Gentoo maintainers leave new versions in ~arch for some
time so they can be tested by a broad set of people. Stabilization
bugs are normally not filed until a given version has spent at least
30 days in ~arch.

See GLEP 40 for details on this process.

https://www.gentoo.org/glep/glep-0040.html

Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Michael Jones
I'll start by saying that I appreciate all the work the Gentoo developers do, and by no means have any animosity for them for this,

Here's an example of how 4.19.97 being stabilized might have exposed users to functionality breaking bugs: https://bugs.gentoo.org/706036

Took me several hours to figure out why several of my machines weren't working right.

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.

As an aside: The gentoo bug tracker has way too many open bugs (Thousands and thousands of them opened over 10 years ago), and the search interface is... frustrating. Took me over 5 minutes to find that bug despite being a commenter on it. Does anyone know if there's any plans for that situation to change in any way?

On Fri, Feb 7, 2020 at 11:56 AM Franz Fellner <[hidden email]> wrote:
That doesn't apply to the kernel.
4.19.97 got tagged on January 17.
January 18. it was stable on amd64 and x86 - one day instead of 30.
Here is the stabilization request: https://bugs.gentoo.org/705006
There were some issues and changes to the targeted versions.


Am Fr., 7. Feb. 2020 um 19:18 Uhr schrieb Mike Gilbert <[hidden email]>:
On Thu, Feb 6, 2020 at 10:23 PM Matt Connell <[hidden email]> wrote:
>
> On 2020-02-06 11:40, Ian Zimmerman wrote:
> > 5.4 has just become the newest LTS.
>
> I see that now.  But my original question still stands as to why the
> stable version of gentoo-sources is consistently a few versions behind
> the latest LTS release.

Typically, Gentoo maintainers leave new versions in ~arch for some
time so they can be tested by a broad set of people. Stabilization
bugs are normally not filed until a given version has spent at least
30 days in ~arch.

See GLEP 40 for details on this process.

https://www.gentoo.org/glep/glep-0040.html

Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Rich Freeman
On Fri, Feb 7, 2020 at 2:34 PM Michael Jones <[hidden email]> wrote:
>
> Here's an example of how 4.19.97 being stabilized might have exposed users to functionality breaking bugs: https://bugs.gentoo.org/706036
>
> 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.

So, in general any newer release should only make things better, but
if a particular release made things much worse you'd only know from
general discussion on high-volume lists.

I follow upstream directly and just tend to hold off a day or two
before updates, and look for signs of chatter before doing so.  That
is hardly optimal.

A company like RedHat just hires a ton of kernel engineers to
basically do their own QA on top of upstream's - they can stay on top
of those sorts of problems.  I'm sure the Gentoo kernel team does a
better job than I personally do, but I doubt they can sink as much
time as that.

> As an aside: The gentoo bug tracker has way too many open bugs
> (Thousands and thousands of them opened over 10 years ago), and the
> search interface is... frustrating. Took me over 5 minutes to find
> that bug despite being a commenter on it. Does anyone know if there's
> any plans for that situation to change in any way?

I doubt it, but the search interface is probably more likely to change
than the number of open bugs.

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.  Obviously
fixing bugs would be the ideal path, but we're volunteer driven, so
that is up to the volunteers.  I mean, we could just remove any
package from the repo that has open bugs older than a certain time,
but that seems likely to just end up with a repo without any packages
in it.  Unless the bugs have security implications or are causing
impact to updates to other packages there usually isn't any policy
requiring that they be fixed.

I'm sure lots of people would be up for improving the UI, though that
still requires volunteer work.  Also, if the fix involves switching
away from bugzilla that is a much bigger hurdle, and one challenge is
that Gentoo doesn't like to host stuff written in Java/Ruby, which
tends to exclude a lot of popular stuff.  I don't sysadmin webservers
for a living, so I won't comment on whether that policy is a good one
or a bad one, but I suspect those behind it know a lot more about
maintaining webservers than I do...

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Michael Jones
On Fri, Feb 7, 2020 at 2:25 PM Rich Freeman <[hidden email]> wrote:
On Fri, Feb 7, 2020 at 2:34 PM Michael Jones <[hidden email]> wrote:
>
> Here's an example of how 4.19.97 being stabilized might have exposed users to functionality breaking bugs: https://bugs.gent was released on Jan 18thoo.org/706036
>
> 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.

So, in general any newer release should only make things better, but
if a particular release made things much worse you'd only know from
general discussion on high-volume lists.

I follow upstream directly and just tend to hold off a day or two
before updates, and look for signs of chatter before doing so.  That
is hardly optimal.

A company like RedHat just hires a ton of kernel engineers to
basically do their own QA on top of upstream's - they can stay on top
of those sorts of problems.  I'm sure the Gentoo kernel team does a
better job than I personally do, but I doubt they can sink as much
time as that.


Again, no animosity against anyone:

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. You don't mind going directly with the upstream package, but I personally do, which is why I used the gentoo-sources package for my kernel needs in large part because I have trust in the Gentoo distribution to provide that small but crucial extra layer of insider knowledge on how likely a particular upstream kernel release is going to break my systems.

I certainly don't have a relationship with Gentoo where I pay money to someone and expect some kind of service level guarantees, so honestly this email is just a lot of hot-air. But if Gentoo wants to provide good experiences to end users who are updating their kernels, I personally think it's worth considering the release cadance and whether the currently used one is the right fit for the actual goals of the project.

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.

 
> As an aside: The gentoo bug tracker has way too many open bugs
> (Thousands and thousands of them opened over 10 years ago), and the
> search interface is... frustrating. Took me over 5 minutes to find
> that bug despite being a commenter on it. Does anyone know if there's
> any plans for that situation to change in any way?

I doubt it, but the search interface is probably more likely to change
than the number of open bugs.

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.  Obviously
fixing bugs would be the ideal path, but we're volunteer driven, so
that is up to the volunteers.  I mean, we could just remove any
package from the repo that has open bugs older than a certain time,
but that seems likely to just end up with a repo without any packages
in it.  Unless the bugs have security implications or are causing
impact to updates to other packages there usually isn't any policy
requiring that they be fixed.

I'm sure lots of people would be up for improving the UI, though that
still requires volunteer work.  Also, if the fix involves switching
away from bugzilla that is a much bigger hurdle, and one challenge is
that Gentoo doesn't like to host stuff written in Java/Ruby, which
tends to exclude a lot of popular stuff.  I don't sysadmin webservers
for a living, so I won't comment on whether that policy is a good one
or a bad one, but I suspect those behind it know a lot more about
maintaining webservers than I do...

--
Rich



Apparently better than it used to be. The last time I surveyed bugzilla itdate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Gentoo%20Linux&query_format=advanced&resolution=---

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.

Bugzilla actually only reports a max of 10,000 open bugs with that search. Which stops at Dec 28th, 2018.

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.

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.

If you're honestly fine with this situation, so be it. However, I really do think Gentoo would be better overall if bugs were automatically closed if the last activity was 10 years ago, and bugs automatically commented on by a bot asking the reporter if the issue is still an issue if the last activity was 5 years ago.

Surely if a bug is open for 10 years without any human interaction at all, it can't have really been that much of a problem to begin with?

Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Michael Jones
Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Dale-46
In reply to this post by Michael Jones
Michael Jones wrote:

Again, no animosity against anyone:

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. You don't mind going directly with the upstream package, but I personally do, which is why I used the gentoo-sources package for my kernel needs in large part because I have trust in the Gentoo distribution to provide that small but crucial extra layer of insider knowledge on how likely a particular upstream kernel release is going to break my systems.

I certainly don't have a relationship with Gentoo where I pay money to someone and expect some kind of service level guarantees, so honestly this email is just a lot of hot-air. But if Gentoo wants to provide good experiences to end users who are updating their kernels, I personally think it's worth considering the release cadance and whether the currently used one is the right fit for the actual goals of the project.

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.


There is a kernel mailing list that posts when there is updates.  You may want to subscribe to that and if nothing else, just monitor it for when there is new updates.  I'm not sure but I think you can reply/post to that list as well if there is a question or problem.

You can subscribe by emailing this address just like you did for this mailing list.

[hidden email]

Hope that helps. 

Dale

:-)  :-) 
Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Rich Freeman
In reply to this post by Michael Jones
On Sun, Feb 9, 2020 at 4:04 PM Michael Jones <[hidden email]> wrote:

>
> On Fri, Feb 7, 2020 at 2:25 PM Rich Freeman <[hidden email]> wrote:
>>
>> On Fri, Feb 7, 2020 at 2:34 PM Michael Jones <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

james-3
In reply to this post by Michael Jones
On 2/9/20 4:08 PM, Michael Jones wrote:


Hello,

Any tricks to product these lists, that are current can truncate/filter
off the oldest, so we can see what's going on?

On 2/4/2020, I also tried to get some momentum going with updating
(maintainer wanted) some packages, and got no responses on that thread.
Here are the (2) links I referenced.


https://qa-reports.gentoo.org/output/maintainer-needed.html


https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide#Proxied_Maintainer_gets


Perhaps a focused effort, including some new volunteers, could bring
many of the packages up to eapi-7 while fixing many minor issues with
the vast majority of these
(bug) packages?

Perhaps GSOC (Google Summer of Code) could/should spend a summer on
cleaning up these packages in the distro?

Sure the many of the wonderful folks that visit gentoo-user would
participate, just a little bit?

Perhaps a concerted effort/document/examples on how to bring eapi-5/6
packages up to eapi-7? A document with a few examples?

Perhaps all of this exist and I just missed it?


curiously,
James






Reply | Threaded
Open this post in threaded view
|

Number of open Bugzilla bugs (Was: Question about gentoo-sources kernel release versions)

Michael Jones
In reply to this post by Rich Freeman

On Sun, Feb 9, 2020 at 5:43 PM Rich Freeman <[hidden email]> wrote:
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.

Or in my case, I sometimes post 1-line pull requests to the Gentoo github, which fix packages being unable to compile, which get rejected because I didn't jump through enough hoops, and the bug remains unfixed for over a year after I open the PR. I stopped posting PRs after that, since it's a waste of my time.

Or I post patches to Bugzilla for some package, the Gentoo maintainer agrees to accept them after Upstream reviews it, and upstream takes 3 years to review, with dead mailing list during that 3 year period.

On the flip side, I regularly see issues get fixed between when I notice the issue, and the issue is reported (by myself in many cases) on Bugzilla.

I'm not attempting to be contradictory for the sake of being contradictory, but the situation is significantly more complicated than what you said, but English is imprecise, so I understand that you're aware of these things.

Filing bugs, or patches, or PRs, or instructions for fixing, or even attempting to get fixes into the appropriate upstream project, regularly results in no outcome for me at all. Neither positive or negative. Just nothing.

Add to that, Gentoo has *so many bugs* that your bug tracking software, when told to simply "Give me all of the bugs" refuses to actually do so.

Why should I continue opening new bugs, (or even better, provide patches) when I have new problems?

I don't see the problem as Gentoo not knowing that there are issues that should be tracked. I see it as a problem of Gentoo can't engage with it's user community in an effective way. And I see having over 10,000 open bugs as one of the barriers between effective user engagement and what we have today.
 
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.

Is there ever a time cutoff, after which a bug should automatically be closed, in your opinion?

I thought my proposal of a single reminder email after 5 years, and then auto-close after 10 years, was reasonable.

Is 10 years for the reminder email, and 20 for the auto-close better?

Surely if something hasn't been addressed in 20 years, it won't be?
 
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?

Yes, it will improve how I feel about it.

Either:
1. The bug hasn't been acted on in the previous 5 years on bugzilla, but maybe it's been fixed and the original reporter / developer forgot to do anything in bugzilla about it. Or no one realized it was fixed. This kind of thing happens all the time.
2. The maintainer of the package in question failed to address the problem, even to acknowledge the problems existence, in the preceding 5 years. Maybe it fell through the cracks? Maybe it's being deliberately ignored? Computers can do things for us automatically, like remind people about things.
 
It seems like picking at a scab when the only people paying attention to a bug are the reporter and a bot.

A scab that's failed to heal in 5 years is a pretty serious injury.
 
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.

So stop making it a waste of people's time?

You're reaction to this suggestion gives me the impression that Gentoo, as a project, considers it to be just fine for issues to be completely untouched for a decade, no acknowledgment, no action.

Do you think that's fine? Or not? I just want to make sure I fully understand your point of view.

Personally, I don't. But I'm not a Gentoo developer, so *shrug*. 

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 | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Michael Jones
In reply to this post by james-3


On Sun, Feb 9, 2020 at 5:55 PM james <[hidden email]> wrote:
Sure the many of the wonderful folks that visit gentoo-user would
participate, just a little bit?

I would be willing to help.

However, if left to my own devices, I would just close anything with no activity for 10 years, and remind the cc list of anything with no activity for 5 years of the bug as the first thing I did.

So any effort that I participate in to try to improve that is going to need the Gentoo developers to give clear instructions on how they want the project to go.
Reply | Threaded
Open this post in threaded view
|

Re: Number of open Bugzilla bugs (Was: Question about gentoo-sources kernel release versions)

Jack
In reply to this post by Michael Jones
[top posting just because ...  and clearly personal opinion]
I file and deal with bugs on both bugs.gentoo.org and bugs.kde.orf, and  
one thing I can say with conviction is that the response to a bug  
varies greatly, and seems to depend on who receives it, possibly being  
per application, per project, per team, or sometimes per individual,  
but which one matters.  Unfortunately, it's not much use to generalize  
about how bugs are handled (or not handled) since there really is such  
a variation.  Even within one application, I've seen some bugs handled  
almost immediately, and others sit for years.

Jack

On 2020.02.09 19:23, Michael Jones wrote:

> On Sun, Feb 9, 2020 at 5:43 PM Rich Freeman <[hidden email]> wrote:
>
> > 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.
>
>
> Or in my case, I sometimes post 1-line pull requests to the Gentoo  
> github,
> which fix packages being unable to compile, which get rejected  
> because I
> didn't jump through enough hoops, and the bug remains unfixed for  
> over a
> year after I open the PR. I stopped posting PRs after that, since  
> it's a
> waste of my time.
>
> Or I post patches to Bugzilla for some package, the Gentoo maintainer
> agrees to accept them after Upstream reviews it, and upstream takes 3  
> years
> to review, with dead mailing list during that 3 year period.
>
> On the flip side, I regularly see issues get fixed between when I  
> notice
> the issue, and the issue is reported (by myself in many cases) on  
> Bugzilla.
>
> I'm not attempting to be contradictory for the sake of being  
> contradictory,
> but the situation is significantly more complicated than what you  
> said, but
> English is imprecise, so I understand that you're aware of these  
> things.
>
> Filing bugs, or patches, or PRs, or instructions for fixing, or even
> attempting to get fixes into the appropriate upstream project,  
> regularly
> results in no outcome for me at all. Neither positive or negative.  
> Just
> nothing.
>
> Add to that, Gentoo has *so many bugs* that your bug tracking  
> software,
> when told to simply "Give me all of the bugs" refuses to actually do  
> so.
>
> Why should I continue opening new bugs, (or even better, provide  
> patches)
> when I have new problems?
>
> I don't see the problem as Gentoo not knowing that there are issues  
> that
> should be tracked. I see it as a problem of Gentoo can't engage with  
> it's
> user community in an effective way. And I see having over 10,000 open  
> bugs
> as one of the barriers between effective user engagement and what we  
> have
> today.
>
>
> > 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.
> >
>
> Is there ever a time cutoff, after which a bug should automatically be
> closed, in your opinion?
>
> I thought my proposal of a single reminder email after 5 years, and  
> then
> auto-close after 10 years, was reasonable.
>
> Is 10 years for the reminder email, and 20 for the auto-close better?
>
> Surely if something hasn't been addressed in 20 years, it won't be?
>
>
> > 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?
>
>
> Yes, it will improve how I feel about it.
>
> Either:
> 1. The bug hasn't been acted on in the previous 5 years on bugzilla,  
> but
> maybe it's been fixed and the original reporter / developer forgot to  
> do
> anything in bugzilla about it. Or no one realized it was fixed. This  
> kind
> of thing happens all the time.
> 2. The maintainer of the package in question failed to address the  
> problem,
> even to acknowledge the problems existence, in the preceding 5 years.  
> Maybe
> it fell through the cracks? Maybe it's being deliberately ignored?
> Computers can do things for us automatically, like remind people about
> things.
>
>
> > It seems like picking at a scab when the only people paying  
> attention to a
> > bug are the reporter and a bot.
> >
>
> A scab that's failed to heal in 5 years is a pretty serious injury.
>
>
> > 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.
> >
>
> So stop making it a waste of people's time?
>
> You're reaction to this suggestion gives me the impression that  
> Gentoo, as
> a project, considers it to be just fine for issues to be completely
> untouched for a decade, no acknowledgment, no action.
>
> Do you think that's fine? Or not? I just want to make sure I fully
> understand your point of view.
>
> Personally, I don't. But I'm not a Gentoo developer, so *shrug*.
>
> 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 | Threaded
Open this post in threaded view
|

Re: Number of open Bugzilla bugs (Was: Question about gentoo-sources kernel release versions)

Rich Freeman
In reply to this post by Michael Jones
On Sun, Feb 9, 2020 at 7:23 PM Michael Jones <[hidden email]> wrote:

>
> On Sun, Feb 9, 2020 at 5:43 PM Rich Freeman <[hidden email]> wrote:
>>
>> 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.
>
> Or in my case, I sometimes post 1-line pull requests to the Gentoo
> github, which fix packages being unable to compile, which get rejected
> because I didn't jump through enough hoops, and the bug remains
> unfixed for over a year after I open the PR. I stopped posting PRs
> after that, since it's a waste of my time.

You could have jumped through all the required hoops and still had it ignored.

> I'm not attempting to be contradictory for the sake of being
> contradictory, but the situation is significantly more complicated
> than what you said

Not sure how that could be.  I literally said "If you do report an
issue it might or might not get fixed."  I'm pretty sure that hits all
the examples you supplied, being that it was basically a tautology.
There simply are no guarantees.

> Add to that, Gentoo has *so many bugs* that your bug tracking
> software, when told to simply "Give me all of the bugs" refuses to
> actually do so.

It generally isn't a problem unless you run queries with no filters at
all.  Sure, if you literally ask it for "all of the bugs" you won't
get them.  So don't ask it for all of them.  I'll note that even if we
closed all the bugs you'd still get the same error unless you only
asked for OPEN bugs.  :)

And if what you want is all old bugs closed, you can just filter by
date, and then you'll get all the benefits of those bugs being
filtered as far as query response limits are concerned.

> Why should I continue opening new bugs, (or even better, provide
> patches) when I have new problems?

Simple.  If you provide a patch or bug you're more likely to get a
response than if you don't.  There are no guarantees either way.

> I don't see the problem as Gentoo not knowing that there are issues
> that should be tracked. I see it as a problem of Gentoo can't engage
> with it's user community in an effective way. And I see having over
> 10,000 open bugs as one of the barriers between effective user
> engagement and what we have today.

I don't see how open bug counts are really the problem here.

Let's suppose we put in a bot that closes all bugs 5 minutes after
they are opened, unconditionally, and locked them.  We'd have nearly
zero open bugs at all times that way.  Obviously that wouldn't
increase user engagement.

I don't think your frustration is really that bugs that were opened 15
years ago by somebody else are still open.  I think your frustration
is that a bug you open tomorrow is reasonably likely to not be fixed.
CLOSED-EXPIRED or whatever isn't the status you want - you want
RESOLVED-FIXED.  And that is completely normal.  However, the only
thing that is going to lead to this is people actually fixing bugs,
not bots playing with statuses.

Gentoo will NEVER engage with its user community in a way you consider
effective by these sorts of standards.  If Gentoo had 50,000
developers that were all super-active we'd STILL have this problem,
because such a high level of quality would bring in millions of users,
and they'd be filing millions of bugs, and those mere 50,000
developers would still not get everything resolved.  Granted, I won't
say that this will scale up infinitely but I think that even
high-quality or professional distros still end up with more bugs than
they can really fix.

>> 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.
>
> Is there ever a time cutoff, after which a bug should automatically be closed, in your opinion?

No.

> Surely if something hasn't been addressed in 20 years, it won't be?

If nobody can bother to fix 20 year old bugs on some piece of
software, why would you be running it today, and thus why would you be
searching for bugs for it?

> Either:
>
> 1. The bug hasn't been acted on in the previous 5 years on bugzilla,
> but maybe it's been fixed and the original reporter / developer
> forgot to do anything in bugzilla about it. Or no one realized it was
> fixed. This kind of thing happens all the time.

Chances are if anybody is maintaining the package then it will
eventually get noticed and fixed.  If nobody is maintaining it then
the open bugs aren't really impeding anybody doing fixes.

> 2. The maintainer of the package in question failed to address
> the problem, even to acknowledge the problems existence, in the
> preceding 5 years. Maybe it fell through the cracks? Maybe it's being
> deliberately ignored? Computers can do things for us automatically,
> like remind people about things.

The only person getting reminded is the requester.  A maintainer that
is deliberately ignoring bugs will be sending bot mail to /dev/null.
If requesters start pinging devs in other ways to get their attention
about such bugs, that seems more likely to just have these devs become
more aggressive about blocking such attempts from users to
communicate.  That's probably part of why so few devs are on this list
at all.  :)

Why would a maintainer acknowledge the existence of a problem they
don't intend to fix?  That is just going to invite somebody nagging
them about it.  There is no penalty for failing to acknowledge a bug,
but there is more likely to be social pressure/etc if somebody acks
that a bug exists and then just ignores it.  I think this is why so
many tend to have such a passive-aggressive stance towards bugs.
Maybe some of the solution is to avoid criticizing devs who ack that a
bug is really serious but that they don't intend to do anything about
it.  That seems unlikely to happen.

I imagine that a lot of bugs fall into the general category of
something a dev thinks should be fixed, but it won't be easy to fix
and it might or might not even be within the dev's skills to fix.  So
they just sit there.

>> 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.
>
> So stop making it a waste of people's time?

Nobody knows how to do that.  It takes effort to fix bugs, and nobody
can make an AI that will tell you up-front whether a bug is likely to
get fixed or not before you bother to file it.

> You're reaction to this suggestion gives me the impression that
> Gentoo, as a project, considers it to be just fine for issues to be
> completely untouched for a decade, no acknowledgment, no action.

I don't speak for Gentoo, as a project. I'm not sure that anybody
really does.  To the extent that they do they generally give nicely
stated answers that try to avoid offending anybody.  :)

> Do you think that's fine? Or not? I just want to make sure I fully
> understand your point of view.

I'm not sure what "fine" even means here.  I don't think it is "fine"
that any software has bugs at all in the first place, or that bugs
aren't fixed within milliseconds of being reported, or that people
everywhere die routinely without even living a full century.  I also
think that there is almost nothing that can be practically done right
now to prevent any of these things, so I don't get worked up about it.

I use Gentoo when it is the best tool for the job, which is often,
IMO.  Other distros have strengths and weaknesses, and different
approaches to bug QA.  Many distros would solve this problem by
removing packages from the repo until it is just a core set of
dependencies and system packages that could be maintained more
responsively, and then everything else is somebody else's problem.
Gentoo tends to prefer to keep stuff in the central repos where it
tends to get at least a bit more QA.  There are pros and cons to
either approach.  Some distros might boot devs who ignore bugs, and
would prefer to just have a very small number of very active devs over
something like what Gentoo has, which is a lot of devs who are only
narrowly active.

I completely get that the world would be a better place if more bugs
get fixed.  Honestly, though, the only concrete suggestion you've
offered is to close old bugs.  I'm skeptical that this would really do
much to improve quality, and the only place you'd notice the change is
in running super-broad queries like "give me all the open bugs" that
nobody doing real work would actually look at.  Maybe superficially it
makes things look better if you don't know what is actually going on.
For those submitting bugs though they're just getting all these bug
closed messages without the bugs being closed.

If I'm maintaining the package foo then I'm going to ask for all the
open foo bugs, and having a few 10 year old bugs in the list is no big
deal.  If the package is actively maintained chances are that somebody
will get around to closing them if they look invalid.  If the package
isn't actively maintained then nobody will even look at the list
except maybe a user, and the fact that 10 year old bugs are sitting
around might be a useful clue that it isn't maintained.

On a side note it looks like my oldest open bug is 12 years old.  I'm
actually not quite sure if it is valid - maybe I'll post a comment and
see...  :)

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

james-3
In reply to this post by Michael Jones
On 2/9/20 7:26 PM, Michael Jones wrote:

>
>
> On Sun, Feb 9, 2020 at 5:55 PM james <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Sure the many of the wonderful folks that visit gentoo-user would
>     participate, just a little bit?
>
>
> I would be willing to help.
>
> However, if left to my own devices, I would just close anything with no
> activity for 10 years, and remind the cc list of anything with no
> activity for 5 years of the bug as the first thing I did.
>
> So any effort that I participate in to try to improve that is going to
> need the Gentoo developers to give clear instructions on how they want
> the project to go.


Fair enough. Regular gentoo code (ebuild) issues are more straightforward.

But, I'm starting on this  'low hanging fruit' now. I.E. converting
smaller ebuilds  which are eapi-5 and eapi-6  to eapi-7. So are there
some cool/easy examples for folks to follow? Dunno.  Perhaps someone
more knowledgeable and current  could suggest a few explicit examples.


 From what I discern, from scanning these packages you previously
alluded to, many are 'maintainer-needed' that have few bugs so they just
need to be updated to eapi-7?


https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers

https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide

https://wiki.gentoo.org/wiki/Tools_for_the_work_as_proxied_maintainer

https://wiki.gentoo.org/wiki/Test_environment


I'm trying to subscribe to the list, as I write this.
I do not like irc_chat.

I like email lists. No irc-chat for me. proxy_maint that is email
centric, works best for me. ymmv.

So far, I've  installed:

colordiff
imediff2
dev-util/meld
x11-misc/zim
dev-util/imediff2
repoman
*tools


Other suggestions and Comments?

James



Reply | Threaded
Open this post in threaded view
|

Re: Question about gentoo-sources kernel release versions

Alessandro Barbieri-2
Il Lun 10 Feb 2020, 03:08 james <[hidden email]> ha scritto:
On 2/9/20 7:26 PM, Michael Jones wrote:
>
>
> On Sun, Feb 9, 2020 at 5:55 PM james <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Sure the many of the wonderful folks that visit gentoo-user would
>     participate, just a little bit?
>
>
> I would be willing to help.
>
> However, if left to my own devices, I would just close anything with no
> activity for 10 years, and remind the cc list of anything with no
> activity for 5 years of the bug as the first thing I did.
>
> So any effort that I participate in to try to improve that is going to
> need the Gentoo developers to give clear instructions on how they want
> the project to go.


Fair enough. Regular gentoo code (ebuild) issues are more straightforward.

But, I'm starting on this  'low hanging fruit' now. I.E. converting
smaller ebuilds  which are eapi-5 and eapi-6  to eapi-7. So are there
some cool/easy examples for folks to follow? Dunno.  Perhaps someone
more knowledgeable and current  could suggest a few explicit examples.


 From what I discern, from scanning these packages you previously
alluded to, many are 'maintainer-needed' that have few bugs so they just
need to be updated to eapi-7?


https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers

https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide

https://wiki.gentoo.org/wiki/Tools_for_the_work_as_proxied_maintainer

https://wiki.gentoo.org/wiki/Test_environment


I'm trying to subscribe to the list, as I write this.
I do not like irc_chat.

I like email lists. No irc-chat for me. proxy_maint that is email
centric, works best for me. ymmv.

So far, I've  installed:

colordiff
imediff2
dev-util/meld
x11-misc/zim
dev-util/imediff2
repoman
*tools


Other suggestions and Comments?

James

You can look at my open and closed pull requests

While I see a lot of enthusiasm, it will get soon crashed by the wait for a dev to merge your PR
12