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 <alpine.art...@gmail.com> 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 <flop...@gentoo.org > >: > >> On Thu, Feb 6, 2020 at 10:23 PM Matt Connell <matthewdconn...@gmail.com> >> 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 >> >>
