Re: [gentoo-project] Re: [gentoo-dev-announce] call for agenda items, council meeting 8/13

[Alice Ferrazzi]

On Tue, Aug 1, 2017 at 10:16 PM, Mike Pagano <mpagano@g.o> wrote:
> On Tue, Aug 01, 2017 at 07:02:58AM -0400, Aaron Bauman wrote:
>> On Tuesday, August 1, 2017 6:35:35 AM EDT Kristian Fiskerstrand wrote:
>> > On 08/01/2017 01:43 AM, Benda Xu wrote:
>> > > Is it feasible to reduce the workload by only stablizing the longterm
>> > > supported kernels?
>> >
>> > On 08/01/2017 12:30 AM, Rich Freeman wrote:
>> > > I'd suggest taking it further and allowing auto-stabilization of all
>> > > point releases whether they're security releases or not.
>> >
>> > Both of these are also in line with what has previously been [discussed
>> > in wg-stable]:
>> > --<---------------------------------------------------->--
>> > \subsection{Kernel}
>> > There should be kernel packages in stable visibility available to end
>> > users for \pkg{sys-kernel/gentoo-sources} and other kernel variants
>> > referenced in the installation instructions of the handbook, in order
to
>> > ease the configuration for new users.
>> >
>> > For Kernel stabilisation it is not possible for an arch tester to test
>> > all possible configuration and hardware combinations. Other kernel
>> > variants, that are expected for more advanced users to begin with,
>> > likely does not make sense to stabilise given there the lack of
>> > stability guarantees. Restricing the number of stabilised kernels hence
>> > aids in reducing arch tester workload.
>> >
>> > As discussed previously\cite{kernel01,kernel02} a consistent
>> > stabilisation policy on kernels is also important in order to ensure
>> > that the latest point release is available to end-users in order to
>> > ensure that security- and bugfixes are offered. In the experience of
the
>> > WG the kernel upstream has a strict policy on maintaining backwards
>> > compatibility and not breaking userspace which has been proven over
time.
>> >
>> > As such it makes sense to
>> > \begin{itemize}
>> >   \item Stabilise Long Term Stable (LTS) branches once they have been
>> > determined to be so and tested downstream
>> >   \item Have an automatic policy of stabilising new point releases
>> > within the LTS
>> >   \item non-LTS branches should not be stabilised
>> > \end{itemize}
>> >
>> > --<---------------------------------------------------->--
>> >
>> > References:
>> > [discussed in wg-stable]
>> > https://download.sumptuouscapital.com/gentoo/wg-stable/main.pdf
>>
>> So will the council consider ratifying the WG stable suggestions for
kernel
>> releases?
>>
>> -Aaron
>
> Thinking about this more..
>
> I'm actually OK with what's written in the WG stable suggestion.  As
> long as this does not imply that we will support every LTS labeled
> kernel from upstream.
>
> Right now we have 8 different versions and back when I started in 2007
> we had a policy to only support 2.
>
> I would still like the Kernel Project to decide which versions to
> support and when to drop versions from the tree.  We're very flexible
> and do respond to user's reasonable requests.
>
> So, if the kernel section of the WG stable document can be voted on
> without the need for the entire document to be blessed please do so.
>
> Mike
>

As now i'm busy with GSoC and university middle term exams (and are both a
full time schedule).

This topic (of stabilization problems) came out already many time over the
past.

Kernel is a particular project and the kernel team is doing the possible
for making it safe and update.
The Kernel upstream system is changing ( and probably will change again in
the future ) and the Gentoo Kernel Project is keeping up in different way
and
developing tools for make us keep up with upstream and shorten the time of
gentoo-sources packaging and releasing.

I think with some work (Gentoo kernel CI is still a protype version), we
could auto stabilize the Kernel using Gentoo kernel CI.
https://wiki.gentoo.org/wiki/Project:Kernel/Kernel_CI

As GSoC project I'm also now making a live patch feature that would be used
in gentoo-sources for patching eventual problems (security fix etc. etc.),
without the need to require to download the new kernel sources and almost
automatically.
https://github.com/aliceinwire/elivepatch

Some arch are complex to stabilize, for example arm32 is not so straight
forward as I fought.
It need to forward port some patches for make it work (looks like lot of
works)
https://github.com/hardkernel/linux/tree/odroidxu4-4.9.y

Because of this arm for example could be just dropped unstable and give as
it is for now, but is anyway a complicate topic and
would be nice to give more investigation in the future.

Ultimately I think is the Kernel Project duty to work case by case, and
decide which kernel to support and which to drop.


-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Mail: Alice Ferrazzi <alicef@g.o>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A