Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[Alessandro Barbieri]

Il Lun 10 Feb 2020, 03:08 james  ha scritto:

> On 2/9/20 7:26 PM, Michael Jones wrote:
> >
> >
> > On Sun, Feb 9, 2020 at 5:55 PM james  > > 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
https://github.com/gentoo/gentoo/pulls?q=is%3Apr+author%3AAlessandro-Barbieri+is%3Aclosed+sort%3Aupdated-desc
https://github.com/gentoo/gentoo/pulls?q=is%3Apr+author%3AAlessandro-Barbieri+sort%3Aupdated-desc+is%3Aopen

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

>

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[james]

On 2/9/20 7:26 PM, Michael Jones wrote:



On Sun, Feb 9, 2020 at 5:55 PM james > 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

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[Michael Jones]

On Sun, Feb 9, 2020 at 5:55 PM james  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.

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[james]

On 2/9/20 4:08 PM, Michael Jones wrote:



On Sun, Feb 9, 2020 at 3:04 PM Michael Jones > wrote:


https://bugs.gentoo.org/buglist.cgi?limit=0=changed



Apparently better than it used to be. The last time I surveyed
bugzilla

itdate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=Gentoo%20Linux_format=advanced=---




Corrected hyperlink:
https://bugs.gentoo.org/buglist.cgi?limit=0=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=Gentoo%20Linux_format=advanced=--- 





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

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[Rich Freeman]

On Sun, Feb 9, 2020 at 4:04 PM Michael Jones  wrote:
>
> On Fri, Feb 7, 2020 at 2:25 PM Rich Freeman  wrote:
>>
>> On Fri, Feb 7, 2020 at 2:34 PM Michael Jones  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 

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[Dale]

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.

gentoo-kernel+subscr...@lists.gentoo.org

Hope that helps. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[Michael Jones]

On Sun, Feb 9, 2020 at 3:04 PM Michael Jones  wrote:

> https://bugs.gentoo.org/buglist.cgi?limit=0=changed
> 
>
> Apparently better than it used to be. The last time I surveyed bugzilla it
> date%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=Gentoo%20Linux_format=advanced=---
> 
>

Corrected hyperlink:
https://bugs.gentoo.org/buglist.cgi?limit=0=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=Gentoo%20Linux_format=advanced=---

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[Michael Jones]

On Fri, Feb 7, 2020 at 2:25 PM Rich Freeman  wrote:

> On Fri, Feb 7, 2020 at 2:34 PM Michael Jones  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
>
>
https://bugs.gentoo.org/buglist.cgi?limit=0=changed


Apparently better than it used to be. The last time I surveyed bugzilla it
date%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=Gentoo%20Linux_format=advanced=---

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[Rich Freeman]

On Fri, Feb 7, 2020 at 2:34 PM Michael Jones  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

Re: [gentoo-user] 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 
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  >:
>
>> On Thu, Feb 6, 2020 at 10:23 PM Matt Connell 
>> 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
>>
>>

Re: [gentoo-user] 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 :

> On Thu, Feb 6, 2020 at 10:23 PM Matt Connell 
> 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
>
>

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[Mike Gilbert]

On Thu, Feb 6, 2020 at 10:23 PM Matt Connell  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

Re: [gentoo-user] 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.

[gentoo-user] Re: Question about gentoo-sources kernel release versions

[Ian Zimmerman]

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