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
|

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

Michael Jones


On Sun, Feb 9, 2020 at 8:07 PM Rich Freeman <[hidden email]> wrote:
You could have jumped through all the required hoops and still had it ignored.

That's pretty horrible, honestly. Why isn't Gentoo doing better than that?

Yes, yes, Gentoo is run by volunteers, so on and so forth. But it's entirely possible (and regularly accomplished in other organizations) to emphasise a culture that actively tries to not ignore low hanging fruit for so long.
 
> 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.

There's what you write, and what other people try to guess as to your meaning. Apparently you intended to mean the tautology, where I instead thought you meant something more interesting than that.

Honestly, this conversation is just making me less interested in contributing to Gentoo in the future. Not only do 1-liner pull requests that fix broken packages get rejected / not fixed for a year, but now I'm being replied to with word-games when I try to discuss the issues that I face as an end-user.

> 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.

My issue is that the list of open bugs is one of many proxy-indicators for other aspects of the Gentoo development process. While fixing the list of open bugs is not directly a fix for any of the potential underlying reasons for the various fuzzy and not clearly identified problems, it will very slightly reduce the overall "badness" while being trivial to implement. I imagine bugzilla already has some kind of plugin that would accomplish this that just needs to be enabled. 
 
> 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.

That's not supported by my experiences. Anecdotes aren't data, but so far the bug's reports and patches that I've provided get ignored, but the issues that I just wait to get fixed for me get fixed.

So it seems to me like I should only file bugs for things that I want to inflict longer wait times on the rest of the community, and I shouldn't file bugs for things I actually want fixed.

If you know of anyone who's attempted to do some statistical modeling of the bug fix rate in Gentoo, I would appreciate being connected to their research so I can stop feeling like a fool for attempting to help.

> 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.

The amount of open bugs, directly, is not the problem.

The problem is that you're lying to people if you keep a bug in bugzilla open for 10+ years.

You know it won't be worked on, they know it won't be worked on. So just close the bug. 

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

No.

Then I'm not going to continue this discussion with you. Your perspective on this is utterly incompatible with mine.
 
> 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?

Then why is it still in the Gentoo package repository?

If it's not in the Gentoo package repository, why is there an open bug in bugzilla about it?
 
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.

Again, this is contrary to my experiences, and what the Gentoo bug tracker has in it.
 
> 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 is that person allowed to be a maintainer for that package then? Sounds like a pretty complete abandonment of responsibility.

And again, if the only person being reminder is the requestor, then it's still a high possibility that they will check to see if the bug was fixed and they didn't realize it, discover that it has been fixed, and then close the bug.

I just did this process last week with another project I'm involved in and had 5 bugs get closed as resolved with end-users reporting they simply didn't realize the bug hadn't been closed before.
 
> 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.

There's a "WONTFIX" resolution in bugzilla. If the maintainer isn't going to fix it, and they mark the issue as WONTFIX, then I won't waste my time waiting. I'll either find another way to do what I'm trying to do, or i'll fix the problem myself, or simply do without.

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.

I get 5-10 year old results almost every time I search for any bug related to problems I'm experiencing. Seeing results from 10 years ago that are still open means I don't report the issue again. But I don't actually know that the maintainer of the package even realizes the old bug is there.

Now you're going to tell me if the old bug was closed automatically, and I opened a new one, that the maintainer of the package is just as likely to do anything about the new bug as the old bug.

And I'm going to pre-emptively respond by saying "Then close it as WONTFIX" so I know not to waste my time, or the "maintainers" time, reporting it.

I'm not suggesting rules or actions related to policing the behavior of Gentoo Developers, because I've seen first hand in the mailing list that the Gentoo Developers will not be amused, to put it mildly, at that kind of suggestion.

So my only recourse, as an end user, is to explain to you the problems I see, and try to offer "concrete" suggestions that involve purely technological solutions. 

Closing bug reports after 10 years isn't perfect. Honestly I'd rather see Gentoo encourage a developer community that doesn't ignore things for a decade. But that's not going to happen, and I'm not suggesting it.

So instead I suggest something that can be implemented, without changing anyone's behavior, and without requiring substantial work from the person implementing the suggestion. 

It's not a perfect solution, but perfect is the enemy of good, after all.
 
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.
 
Why is Gentoo shipping packages that aren't maintained? Isn't that what the "last rights" emails I get from time to time are all about?

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


As stated in the middle of this reply, your perspective on this is completely incompatible with mine, so I won't continue this conversation.

Nevertheless, thank you for discussing it with me
 
Reply | Threaded
Open this post in threaded view
|

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

Dale-46
Michael Jones wrote:


On Sun, Feb 9, 2020 at 8:07 PM Rich Freeman <[hidden email]> wrote:
You could have jumped through all the required hoops and still had it ignored.

That's pretty horrible, honestly. Why isn't Gentoo doing better than that?

Yes, yes, Gentoo is run by volunteers, so on and so forth. But it's entirely possible (and regularly accomplished in other organizations) to emphasise a culture that actively tries to not ignore low hanging fruit for so long.
 
> 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.

There's what you write, and what other people try to guess as to your meaning. Apparently you intended to mean the tautology, where I instead thought you meant something more interesting than that.

Honestly, this conversation is just making me less interested in contributing to Gentoo in the future. Not only do 1-liner pull requests that fix broken packages get rejected / not fixed for a year, but now I'm being replied to with word-games when I try to discuss the issues that I face as an end-user.

> 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.

My issue is that the list of open bugs is one of many proxy-indicators for other aspects of the Gentoo development process. While fixing the list of open bugs is not directly a fix for any of the potential underlying reasons for the various fuzzy and not clearly identified problems, it will very slightly reduce the overall "badness" while being trivial to implement. I imagine bugzilla already has some kind of plugin that would accomplish this that just needs to be enabled. 
 
> 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.

That's not supported by my experiences. Anecdotes aren't data, but so far the bug's reports and patches that I've provided get ignored, but the issues that I just wait to get fixed for me get fixed.

So it seems to me like I should only file bugs for things that I want to inflict longer wait times on the rest of the community, and I shouldn't file bugs for things I actually want fixed.

If you know of anyone who's attempted to do some statistical modeling of the bug fix rate in Gentoo, I would appreciate being connected to their research so I can stop feeling like a fool for attempting to help.

> 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.

The amount of open bugs, directly, is not the problem.

The problem is that you're lying to people if you keep a bug in bugzilla open for 10+ years.

You know it won't be worked on, they know it won't be worked on. So just close the bug. 

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

No.

Then I'm not going to continue this discussion with you. Your perspective on this is utterly incompatible with mine.
 
> 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?

Then why is it still in the Gentoo package repository?

If it's not in the Gentoo package repository, why is there an open bug in bugzilla about it?
 
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.

Again, this is contrary to my experiences, and what the Gentoo bug tracker has in it.
 
> 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 is that person allowed to be a maintainer for that package then? Sounds like a pretty complete abandonment of responsibility.

And again, if the only person being reminder is the requestor, then it's still a high possibility that they will check to see if the bug was fixed and they didn't realize it, discover that it has been fixed, and then close the bug.

I just did this process last week with another project I'm involved in and had 5 bugs get closed as resolved with end-users reporting they simply didn't realize the bug hadn't been closed before.
 
> 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.

There's a "WONTFIX" resolution in bugzilla. If the maintainer isn't going to fix it, and they mark the issue as WONTFIX, then I won't waste my time waiting. I'll either find another way to do what I'm trying to do, or i'll fix the problem myself, or simply do without.

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.

I get 5-10 year old results almost every time I search for any bug related to problems I'm experiencing. Seeing results from 10 years ago that are still open means I don't report the issue again. But I don't actually know that the maintainer of the package even realizes the old bug is there.

Now you're going to tell me if the old bug was closed automatically, and I opened a new one, that the maintainer of the package is just as likely to do anything about the new bug as the old bug.

And I'm going to pre-emptively respond by saying "Then close it as WONTFIX" so I know not to waste my time, or the "maintainers" time, reporting it.

I'm not suggesting rules or actions related to policing the behavior of Gentoo Developers, because I've seen first hand in the mailing list that the Gentoo Developers will not be amused, to put it mildly, at that kind of suggestion.

So my only recourse, as an end user, is to explain to you the problems I see, and try to offer "concrete" suggestions that involve purely technological solutions. 

Closing bug reports after 10 years isn't perfect. Honestly I'd rather see Gentoo encourage a developer community that doesn't ignore things for a decade. But that's not going to happen, and I'm not suggesting it.

So instead I suggest something that can be implemented, without changing anyone's behavior, and without requiring substantial work from the person implementing the suggestion. 

It's not a perfect solution, but perfect is the enemy of good, after all.
 
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.
 
Why is Gentoo shipping packages that aren't maintained? Isn't that what the "last rights" emails I get from time to time are all about?

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


As stated in the middle of this reply, your perspective on this is completely incompatible with mine, so I won't continue this conversation.

Nevertheless, thank you for discussing it with me
 


You might want to take note of the email address for Rich.  He is a developer and has a better understanding of the inner workings of Gentoo.  When he posts about how things work within Gentoo, he does it with knowledge that most users don't have. 

The thing about Gentoo is this.  There's not enough manpower to do everything that every user wants.  If a user wants something that the current devs can't deliver, then that user has few options.  If that user is capable of creating a patch to fix a bug, then they can do so and apply that patch locally.  If that user can help with the ebuild and post patches/fixes to BGO, git or whatever then they can do that.  However, it still falls to the active dev as to whether he/she applies it or not.  It could be that the patch fixes one problem but creates another based on USE flags etc.  The devs do tend to test fixes before putting them in the tree even if the test may be limited in scope.  The other option is to wait for someone else to fix it, the bug to be fixed by the dev etc.  I fall into the last category because I don't code.  Even my scripts don't deserve to be called that but I don't think there is a name for my little script thingys. 

Ignore Rich if you want but you would be the one missing out on inside info. 

Dale

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

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

Michael Jones

You might want to take note of the email address for Rich.  He is a developer and has a better understanding of the inner workings of Gentoo.  When he posts about how things work within Gentoo, he does it with knowledge that most users don't have. 

The thing about Gentoo is this.  There's not enough manpower to do everything that every user wants.  If a user wants something that the current devs can't deliver, then that user has few options.  If that user is capable of creating a patch to fix a bug, then they can do so and apply that patch locally.  If that user can help with the ebuild and post patches/fixes to BGO, git or whatever then they can do that.  However, it still falls to the active dev as to whether he/she applies it or not.  It could be that the patch fixes one problem but creates another based on USE flags etc.  The devs do tend to test fixes before putting them in the tree even if the test may be limited in scope.  The other option is to wait for someone else to fix it, the bug to be fixed by the dev etc.  I fall into the last category because I don't code.  Even my scripts don't deserve to be called that but I don't think there is a name for my little script thingys. 

Ignore Rich if you want but you would be the one missing out on inside info. 

Dale

:-)  :-) 

Thank you Dale.

I'm well aware of who Rich is. That's why I was discussing the subject with him in the first place. 
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
I just wanted to preface this that my intent has been to be frank with
you, and I appreciate that you have done the same.  I appreciate that
you have a different perspective and I think it is actually a pretty
common one.

So, take what I say for what it is worth, and I certainly won't be
offended if you remain in disagreement, and if you feel that a
different distro would better suit your needs I certainly wouldn't
find that offensive at all either.

Also, bear in mind that I speak for nobody but myself but I do think
that some of my observations are fairly accurate in general, and most
seem to agree with your own.

On Mon, Feb 10, 2020 at 3:48 PM Michael Jones <[hidden email]> wrote:
>
> On Sun, Feb 9, 2020 at 8:07 PM Rich Freeman <[hidden email]> wrote:
>>
>> You could have jumped through all the required hoops and still had it ignored.
>
> That's pretty horrible, honestly. Why isn't Gentoo doing better than that?

Simple, "Gentoo" can't do anything - it has no hands, no feet, no
brain.  It is a collection of volunteers.  They work on what they wish
to work on.  That means that some things end up being worked on by
nobody.

That said, plenty do work on proxy maintaining and IMO are doing
better in this area than has been at some points in the past.

> Yes, yes, Gentoo is run by volunteers, so on and so forth. But it's entirely possible (and regularly accomplished in other organizations) to emphasise a culture that actively tries to not ignore low hanging fruit for so long.

Most devs work on the things that interest them.  If your contribution
is in an area that no devs find interesting, then you're offering
low-hanging fruit that doesn't taste very good.  It might be easy to
grasp, but nobody wants to eat it.

That is just an analogy.  I'm not saying that NOBODY will find the
contribution useful.  But, it could very well be that no devs
interested in proxy-maintaining happen to find it personally useful.

>> > 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.
>
> Honestly, this conversation is just making me less interested in contributing to Gentoo in the future. Not only do 1-liner pull requests that fix broken packages get rejected / not fixed for a year, but now I'm being replied to with word-games when I try to discuss the issues that I face as an end-user.

I completely get that you find the absence of any guarantee
frustrating.  I was just telling you the truth.  You could do
everything right and end up being completely ignored.  This seems to
match your own observations.  That isn't meant as a word-game.  Just
as frank conversation.

> The problem is that you're lying to people if you keep a bug in bugzilla open for 10+ years.
>
> You know it won't be worked on, they know it won't be worked on. So just close the bug.

Actually, I don't agree with this.  Leaving a bug open makes no
statement at all about whether it will be worked on.

I guess it is a bit like the debate about whether agnostics are atheists.  :)

It is entirely possible a 10 year old bug will get worked on - it just
takes somebody interested to start looking at it.

>>
>> > 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?
>
>
> Then why is it still in the Gentoo package repository?

Maybe the package works fine for the most part.  Just because a
package has a bug doesn't mean that it is useless.  Why remove a
mostly-working piece of software over a minor bug?

>
> If it's not in the Gentoo package repository, why is there an open bug in bugzilla about it?

You can file a bug to request having something added to the
repository, so there are actually many bugs pertaining to software
that isn't in the repo.

>> 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 is that person allowed to be a maintainer for that package then? Sounds like a pretty complete abandonment of responsibility.

Just because somebody ignores a bug doesn't mean that they aren't
maintaining a package.

Suppose a maintainer ignores 99 bugs and fixes 1?  Let's fix that by
making them no longer a maintainer.  Now the package has no
maintainer, so instead of 99% of future bugs being ignored for it,
instead 100% of future bugs are ignored.  :)

All bugs involve effort and reward, and also a skillset to fix.  A
maintainer might perceive the effort for a bug isn't worth the reward,
or may not have the skillset to fix it.

> There's a "WONTFIX" resolution in bugzilla. If the maintainer isn't going to fix it, and they mark the issue as WONTFIX, then I won't waste my time waiting. I'll either find another way to do what I'm trying to do, or i'll fix the problem myself, or simply do without.

Maintainers WONTFIX bugs all the time if they know they won't be
fixed.  However, many bugs fall into the category that they're
definitely bugs that should be fixed, but the maintainer reviewing the
bug doesn't have the skills to fix that bug in a manner that is worth
their time.

Maybe another maintainer will want to fix it.  Maybe another user will
want to contribute a patch.  It seems a bit much to WONTFIX a valid
bug simply because a particular maintainer doesn't want to fix it
right away.

> I'm not suggesting rules or actions related to policing the behavior of Gentoo Developers, because I've seen first hand in the mailing list that the Gentoo Developers will not be amused, to put it mildly, at that kind of suggestion.

:)

Ultimately devs work on what they want to work on.  As long as they're
making net-positive contributions this is generally considered a good
thing for the project.

If a dev ignores 99 useful suggestions and does 1 positive thing, and
doesn't otherwise do anything negative, they've made Gentoo a better
place.  Booting them would just mean that they aren't doing anything
positive.

It is another matter when they're doing something negative.  And I do
hope you don't see my being frank as a negative.  I think a lot of
projects would just put a PR face on this sort of interaction.  I do
that sort of thing at work all the time and I could give you a
bazillion neutral non-committal answers to basically stall you into
oblivion until you quietly went away.  That isn't my intent.  I don't
get paid by the number of users we have - I hope that Gentoo is useful
for many people, but in the end I realize it isn't the right solution
for every problem and I don't try to pretend that it is otherwise.

> It's not a perfect solution, but perfect is the enemy of good, after all.

I agree.  My main objection to your solution is that it is more
cosmetic, and I tend to prefer non-committal responses in the absence
of knowledge.

I think that WONTFIX should be reserved for bugs that we KNOW won't be
fixed.  If we are 99.999% sure it won't get fixed but there is a
0.001% chance somebody might come along and fix it, because it really
is something that should be fixed even if it will take a lot of work,
then I'd prefer to see it stay open.

But, that is a matter of taste.  Others probably feel otherwise, and I
bet plenty of devs do WONTFIX bugs like these.  I don't maintain their
packages and they can do as they wish with them.

> Why is Gentoo shipping packages that aren't maintained? Isn't that what the "last rights" emails I get from time to time are all about?

Those tend to be applied to packages that aren't maintained and which
have serious problems.  If a package seems to work fine for the most
part not having a maintainer isn't considered a reason to last-rite
it.  It depends on the severity of bugs.

>
> Nevertheless, thank you for discussing it with me
>

You're welcome.  You're hardly the first person to disagree with me.  :)

I'm also not in any particular position of power when it comes to how
bugs are handled.  You can always make a proposal to automatically
close old bugs.  I'd probably start with the Bug Wranglers, though you
could always bring an issue to the Council if you don't feel you're
getting the desired response there.  They've certainly been known to
disagree with me at times too.  :)

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Number of open Bugzilla bugs

Kai Peter
On 2020-02-11 00:06, Rich Freeman wrote:

>>
>> Nevertheless, thank you for discussing it with me
>>
>
> You're welcome.  You're hardly the first person to disagree with me.  
> :)
>
> I'm also not in any particular position of power when it comes to how
> bugs are handled.  You can always make a proposal to automatically
> close old bugs.  I'd probably start with the Bug Wranglers, though you
> could always bring an issue to the Council if you don't feel you're
> getting the desired response there.  They've certainly been known to
> disagree with me at times too.  :)

Interesting discussion. To bad that it's over. Not so much from the
technical site, but the different POV's. Michael tries to improve
things, make things better. Rich stays with the common 'it is like it is
and it is good'. An example to the big view:

https://web.archive.org/web/20080331092730/http://www.linux.com/articles/60124

Even if I tend to Michael's side, I don't say Rich is wrong. To me the
truth is in the middle, always.

--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

Reply | Threaded
Open this post in threaded view
|

Re: Number of open Bugzilla bugs

Mark Knecht


On Fri, Feb 14, 2020 at 12:21 PM Kai Peter <[hidden email]> wrote:

>
> On 2020-02-11 00:06, Rich Freeman wrote:
>
> >>
> >> Nevertheless, thank you for discussing it with me
> >>
> >
> > You're welcome.  You're hardly the first person to disagree with me.
> > :)
> >
> > I'm also not in any particular position of power when it comes to how
> > bugs are handled.  You can always make a proposal to automatically
> > close old bugs.  I'd probably start with the Bug Wranglers, though you
> > could always bring an issue to the Council if you don't feel you're
> > getting the desired response there.  They've certainly been known to
> > disagree with me at times too.  :)
>
> Interesting discussion. To bad that it's over. Not so much from the
> technical site, but the different POV's. Michael tries to improve
> things, make things better. Rich stays with the common 'it is like it is
> and it is good'. An example to the big view:
>
> https://web.archive.org/web/20080331092730/http://www.linux.com/articles/60124
>
> Even if I tend to Michael's side, I don't say Rich is wrong. To me the
> truth is in the middle, always.
Well, ok, a view from the very distant other side. Don't take anything I say as anything other than my opinion which at this point is woefully out of date about Gentoo I'm sure.

1) I started running Gentoo mid-2001, or possibly 2002. I had been running Redhat, a friend who was a real sys admin type vs me, nothin' but a 'user', said it was great and I should check it out. It wasn't overly difficult to get started but I certainly had my issues, like one time removing my C compiler. Real newbie stuff. However once I got my first machine up and running I was really happy with both the machine and most of all this community which is second to none. In those days getting my first machine really buttoned down was like a 2-3 week event.

2) For many years my machines ran really well and admin wasn't a big deal. Yes, hours upon hours upon hours of building programs - the Gentoo way - but they usually built. I was always a 'mostly stable' guy, only adding ~arch when I had to. There wasn't a lot of that, at least in the beginning. I remember this being how I ran until about 2016. There were some difficult months, but devs got things fixed pretty fast and I could, for the most part depend that if I had to install an ~arch package that within a month I could probably get back to stable.

3) From my perspective this lasted until 2015/16/17-ish. However somewhere in there I consistently found two things:
   1) Getting an arch package back to stable in a timely manner pretty much didn't work anymore. I suspect this is really the other thread here about long term bugs not getting fixed. Why? I don't know. I suspected devs were leaving the distro, but I had no info.
   2) This is just my opinion but I came to think there was no real __interest__ from the devs still here in purely stable anymore. I remember trying to set up  a Virtualbox VM running Gentoo and it almost didn't work. I had to add so many use flags. At that point it just wasn't fun anymore. Throw in that I had 3 machines to deal with at home and it was too much for user type who wasn't having fun.

4) I tried out a few other distros and pretty quickly focused in on Kubuntu. I've been running it for a couple of years now. Frankly, I can hardly tell the difference from Gentoo when I'm just using the machine. It's fast, it's KDE, it's all I need. I don't know much more than a couple of apt commands to install packages. No update in the 2-3 years I've been using Kubuntu hasn't booted. I don't have any trouble installing the packages I need that in the Gentoo world would have caused me ~arch problems. (Mixbus32C, makemkv, handbrake and other pro-audio type packages) Updates to my machines are on the order of LITERALLY minutes per week, and distribution upgrades, once a year-ish, are on the order of an hour. The machines all seem fast. It's simple.

I love this list and the people on it. For the most part everyone here has been really great to me over the years and there's no place I'd rather go looking for technical answers. Stack Overflow does tend to be the Ubuntu way these days so lots of little things I need to know I find there. I suspect many Gentoo-ers do also.

Anyway, it's just an opinion of one guy not representing what state the distribution is in today.

Mark
Reply | Threaded
Open this post in threaded view
|

Re: Number of open Bugzilla bugs

Marc Joliet
Well, to steal a German phrase, here's my own mustard in the mix:

Am Freitag, 14. Februar 2020, 23:52:32 CET schrieb Mark Knecht:

> On Fri, Feb 14, 2020 at 12:21 PM Kai Peter <[hidden email]> wrote:
> > On 2020-02-11 00:06, Rich Freeman wrote:
> > >> Nevertheless, thank you for discussing it with me
> > >
> > > You're welcome.  You're hardly the first person to disagree with me.
> > >
> > > :)
> > >
> > > I'm also not in any particular position of power when it comes to how
> > > bugs are handled.  You can always make a proposal to automatically
> > > close old bugs.  I'd probably start with the Bug Wranglers, though you
> > > could always bring an issue to the Council if you don't feel you're
> > > getting the desired response there.  They've certainly been known to
> > > disagree with me at times too.  :)
> >
> > Interesting discussion. To bad that it's over. Not so much from the
> > technical site, but the different POV's. Michael tries to improve
> > things, make things better. Rich stays with the common 'it is like it is
>
> > and it is good'. An example to the big view:
> https://web.archive.org/web/20080331092730/http://www.linux.com/articles/601
> 24
> > Even if I tend to Michael's side, I don't say Rich is wrong. To me the
> > truth is in the middle, always.
Personally, for me all those open bugs seem like a symptom of bad bug hygiene.
Maybe it's not really, and those are just bugs that were left behind in
turbulence, so-to-say (e.g., devs retiring, packages becoming obsolete,
whatever), but personally, I care about closing bugs that are done with or
can't be acted upon.  Perhaps its a matter of workflow, because I treat bugs
as a sort of TODO list, but that's my take on it.  I honestly think it would
be best to close bugs that are just not applicable anymore, e.g., for ebuilds
or versions of packages that have not been in the tree for a looong time,
like, say, HAL: https://bugs.gentoo.org/401257.

But like I say below: that's *work*, even closing bugs that are 10 years old
might clean up stuff that's more of a task than an actual bug (i.e., something
somebody wants to work on at some point), so you'd have to go over them, at
least superficially.  Also: Rich does have a point in the bugs being open not
necessarily mattering much in practice.  But for me, I *do* occasionally look
at all bugs assigned to or authored by me in case I forgot about something,
and having ancient open bugs would be infuriating to me, so I wonder what
workflow projects like "freedesktop" have that it's not a problem for them (or
maybe it's a defunct project and nobody is even looking).

> Well, ok, a view from the very distant other side. Don't take anything I
> say as anything other than my opinion which at this point is woefully out
> of date about Gentoo I'm sure.
>
> 1) I started running Gentoo mid-2001, or possibly 2002. I had been running
> Redhat, a friend who was a real sys admin type vs me, nothin' but a 'user',
> said it was great and I should check it out. It wasn't overly difficult to
> get started but I certainly had my issues, like one time removing my C
> compiler. Real newbie stuff. However once I got my first machine up and
> running I was really happy with both the machine and most of all this
> community which is second to none. In those days getting my first machine
> really buttoned down was like a 2-3 week event.
>
> 2) For many years my machines ran really well and admin wasn't a big deal.
> Yes, hours upon hours upon hours of building programs - the Gentoo way -
> but they usually built. I was always a 'mostly stable' guy, only adding
> ~arch when I had to. There wasn't a lot of that, at least in the beginning.
> I remember this being how I ran until about 2016. There were some difficult
> months, but devs got things fixed pretty fast and I could, for the most
> part depend that if I had to install an ~arch package that within a month I
> could probably get back to stable.
Ah, I still run my machines that way: packages where I want new versions
because of a bug fix or feature that's important to me will get unmasked, and
I'll try to keep track of if/when they go stable.  However...

> 3) From my perspective this lasted until 2015/16/17-ish. However somewhere
> in there I consistently found two things:
>    1) Getting an arch package back to stable in a timely manner pretty much
> didn't work anymore. I suspect this is really the other thread here about
> long term bugs not getting fixed. Why? I don't know. I suspected devs were
> leaving the distro, but I had no info.
>    2) This is just my opinion but I came to think there was no real
> __interest__ from the devs still here in purely stable anymore. I remember
> trying to set up  a Virtualbox VM running Gentoo and it almost didn't work.
> I had to add so many use flags. At that point it just wasn't fun anymore.
> Throw in that I had 3 machines to deal with at home and it was too much for
> user type who wasn't having fun.
... I totally see this, too.  When I started with Gentoo (2007ish) I based my
install on Sabayon, but quickly reverted to vanilla Gentoo for simplicity's
sake.  The Sabayon install set ACCEPT_KEYWORDS="~amd64", but I was able to
change that to "amd64", downgrade various packages, and unmask whatever had to
stay at ~arch (e.g., glibc) and wait until it upgraded to stable.  That took
about 2-3 months, as I recall.  The vast majority was done within 1-2 months.
Today I've been living with most of my current unmask entries for months or
years.  Although, half of those are in overlays or games (which are "banned"
from stable), but the other half are packages with either really old stable
version or none at all (they upgrade, but then older versions are removed
instead of being stabilized).

However, two points here:

1.) Lots of important software *does* receive regular stable upgrades (e.g.,
KDE, all core system packages such as gentoo-sources and glibc, Gnome).
AFAICT, for me it's pretty much only "niche" software that doesn't get stable
versions.

2.) I understand that there just isn't enough man power to go around, so I
don't see any point in complaining and just try to manage as best I can.  If
Gentoo manages to recover from its lack of manpower (and I hope it does), I
expect that the set of packages receiving stabilizations will grow again.

> 4) I tried out a few other distros and pretty quickly focused in on
> Kubuntu. I've been running it for a couple of years now. Frankly, I can
> hardly tell the difference from Gentoo when I'm just using the machine.
> It's fast, it's KDE, it's all I need. I don't know much more than a couple
> of apt commands to install packages. No update in the 2-3 years I've been
> using Kubuntu hasn't booted. I don't have any trouble installing the
> packages I need that in the Gentoo world would have caused me ~arch
> problems. (Mixbus32C, makemkv, handbrake and other pro-audio type packages)
> Updates to my machines are on the order of LITERALLY minutes per week, and
> distribution upgrades, once a year-ish, are on the order of an hour. The
> machines all seem fast. It's simple.
My laptop has openSUSE Tumbleweed, because, well, I want a rolling release
distro and for some reason didn't want to try Arch Linux (although I probably
will at some point).  Oh, and I just felt like trying something different,
hence why I didn't stick with Gentoo [0] (my desktop and two home servers
remain on Gentoo, though).  Although, now that I think about it, openSUSE has
one leg up against Arch: it's the only mainstream distro that supports BTRFS,
my main file system of choice (SUSE even employs several of its developers).

> I love this list and the people on it. For the most part everyone here has
> been really great to me over the years and there's no place I'd rather go
> looking for technical answers. Stack Overflow does tend to be the Ubuntu
> way these days so lots of little things I need to know I find there. I
> suspect many Gentoo-ers do also.
>
> Anyway, it's just an opinion of one guy not representing what state the
> distribution is in today.

FWIW, I'm not so sure about the community *overall*, especially when it comes
to the typical inflammatory topics (e.g., systemd, pulseaudio); that is, when
things heat up, they can get *really* hot.  Though perhaps its just a few bad
experiences that manage to color my overall perception, or I'm just seeing
things overly negative right now, because there are certainly also plenty of
good people here, and I'm with you in that I prefer to ask technical questions
(even not directly relating to Gentoo) in this community as well (although my
first step is always to research things myself, meaning I almost never have to
ask for help here in the first place).

> Mark

[0] A VM doesn't cut it for me in this case, I feel one needs to use a system
in everyday practice to really get a feel for it.  I already get that for
Ubuntu at work and University, and can confidently say it's not for me.

Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Number of open Bugzilla bugs

Rich Freeman
On Fri, Feb 14, 2020 at 7:25 PM Marc Joliet <[hidden email]> wrote:
>
> personally, I care about closing bugs that are done with or
> can't be acted upon.

As do I.

> I honestly think it would
> be best to close bugs that are just not applicable anymore, e.g., for ebuilds
> or versions of packages that have not been in the tree for a looong time,

Certainly.

> like, say, HAL: https://bugs.gentoo.org/401257.

That isn't a HAL bug - it is a bug for a relatively recent version of pm-utils.

I'm not sure if the bug is still an issue, but it could very well be.

And that is the issue with just closing bugs because they're old.
They can still be issues.

If an issue no longer exists then of course the bug should be closed.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Number of open Bugzilla bugs

Kai Peter
On 2020-02-15 01:46, Rich Freeman wrote:

> On Fri, Feb 14, 2020 at 7:25 PM Marc Joliet <[hidden email]> wrote:
>>
>> personally, I care about closing bugs that are done with or
>> can't be acted upon.
>
> As do I.
>
>> I honestly think it would
>> be best to close bugs that are just not applicable anymore, e.g., for
>> ebuilds
>> or versions of packages that have not been in the tree for a looong
>> time,
>
> Certainly.
>
>> like, say, HAL: https://bugs.gentoo.org/401257.
>
> That isn't a HAL bug - it is a bug for a relatively recent version of
> pm-utils.
This is one of the issues with a general discussion of overridden
points: switch to an unimportant detail (of an example).
>
> I'm not sure if the bug is still an issue, but it could very well be.
You don't know, I don' know, nobody is sure, so maybe it could be
possible (perhaps) that it could be happen (under some circumstances)
that the package with major version 2 - which is replaced by major
version 3 already (since some time) - ...  hm, in the meanwhile I did
forget what I wanted to say. So keep all like it is (sarcasm).
>
> And that is the issue with just closing bugs because they're old.
> They can still be issues.
Seeing this as an issue is less than ...  - to me it is wasted time and
resources(?). Just as above.

My way was (and is?) similar to Marc's and Mark's one. I couldn't agree
with some changes in the direction Gentoo is going. It looks a bit like
swarm intelligence. I don't make everything right, but I do think - NOT
believe!. And I'm able to see/correct the cases when I did things wrong.

Nothing personal, just IMHO. Will I get banned from this list now?

>
> If an issue no longer exists then of course the bug should be closed.
Why doesn't this not happen?

--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

Reply | Threaded
Open this post in threaded view
|

Re: Number of open Bugzilla bugs

Rich Freeman
On Sat, Feb 15, 2020 at 8:39 AM Kai Peter <[hidden email]> wrote:

>
> On 2020-02-15 01:46, Rich Freeman wrote:
> > On Fri, Feb 14, 2020 at 7:25 PM Marc Joliet <[hidden email]> wrote:
> >>
> >
> >> like, say, HAL: https://bugs.gentoo.org/401257.
> >
> > That isn't a HAL bug - it is a bug for a relatively recent version of
> > pm-utils.
> This is one of the issues with a general discussion of overridden
> points: switch to an unimportant detail (of an example).

Actually, I only brought it up because it actually is a pretty good
illustration with the problem here.  It is really easy to run a query
and get a bunch of results and extrapolate from there.

The problem is that when you actually start looking at the results
you're returning they are a lot more nuanced.

I am certain that there are plenty of open bugs that are no longer
valid or which were resolved upstream and so on.  The problem is that
it takes a fair bit of effort to actually identify these without just
closing out a ton of bugs wholesale which are still valid and
relevant.

> I couldn't agree
> with some changes in the direction Gentoo is going. It looks a bit like
> swarm intelligence.

That is hardly a change.  Gentoo has been basically operating like a
swarm intelligence for most of its existence.  That was less the case
in the drobbins days, but that was a long time ago.

Now Gentoo is largely an amalgamation of volunteer developers working
on their personal interests with some common rules and a very minimal
shared set of values.  It has been this way for a good 10-15 years
really.

It is a model that actually works pretty well for many things.
Closing bugs isn't one of them, however, as:

1.  Many packages were put there by somebody who was interested in
them at the time and is either no longer around or is no longer
interested, and these can be targets of bugs.
2.  Any dev can work on whatever they want, not necessarily the stuff
that most of the bugs are open for.
3.  Since anybody could take up an interest in anything at any time,
nobody can say with confidence that a particular bug will or won't get
fixed in the next week.  Maybe nobody today is interested in fixing
it, but somebody new could show up tomorrow and work on it.

It is a very bottom-up approach.  It is basically the opposite of
something like Agile where you target some MVP and everybody focuses
on a narrow scope to get a bolus of work done.

> Nothing personal, just IMHO. Will I get banned from this list now?

Nobody gets banned from lists for having an opinion.  It is pretty
hard to get banned in general but it tends to happen when it starts to
turn into harassment/spam or gets personal.  Basically see the code of
conduct.  Having an opinion on something isn't really a problem.
Misinformation can become a problem but it has to be pretty bad before
anything is done.

> >
> > If an issue no longer exists then of course the bug should be closed.
> Why doesn't this not happen?

That goes back to the example above.  To know if an issue still exists
somebody needs to investigate.

The reason that no developer has investigated all those ancient bugs
is the same as the reason you personally haven't investigated them.
There just isn't any particular individual interested in doing it.

If somebody wanted to propose a bug cleanup crew project that went
looking to close out old bugs with some defined rules around what
they're going to do, I bet there would be support for it, as long as
the rules seemed reasonable.  I doubt anybody is going to get
push-back for closing bugs for stuff that is no longer in the tree, or
which doesn't apply to current versions in the tree, and so on.  Where
you'd hit controversy is stuff that probably is still valid but just
has nobody interested in fixing it right now.

But, IMO it is a lot of work for little reward.  I think some of this
is the whole "sort vs search" email workflow argument.  Different
people have different preferences, but for stuff that probably won't
get looked at much it makes more sense to not invest a ton of effort
into housekeeping.  If you spent a lot of time closing out 30 out of
40 bugs for some unmaintained package, the other 10 will still sit and
rot for quite a while.  If the bugs were bad enough to be causing
serious issues chances are the treecleaners would have already caught
it.  Things like security bugs aren't treated the same as "package
randomly doesn't build in this 0.1% edge case with a simple
workaround."

--
Rich

12