On Fri, Feb 7, 2020 at 2:25 PM Rich Freeman <ri...@gentoo.org> wrote:
> On Fri, Feb 7, 2020 at 2:34 PM Michael Jones <gen...@jonesmz.com> wrote: > > > > 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 <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. > > 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&order=changed <https://bugs.gentoo.org/buglist.cgi?limit=0&order=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Gentoo%20Linux&query_format=advanced&resolution=---> Apparently better than it used to be. The last time I surveyed bugzilla it date%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Gentoo%20Linux&query_format=advanced&resolution=--- <https://bugs.gentoo.org/buglist.cgi?limit=0&order=changeddate%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?
