On 05/07/18 06:16, Alice Ferrazzi wrote: > Hello everyone, > > I would like to start the first Gentoo kernel meeting. > Please choose the time of the meeting [1] > If the time is not compatible we can also just discuss it by mail. > > Please send any new agenda items as new threads to the gentoo-kernel list. > > The current agenda is as follows. > - Gentoo kernel ci > - Use Lava qemu for testing the kernel > - Add kselftest > - Start stabilizing with Gentoo kernel CI > - Add ck-sources to the qemu test > - Stabilization > - Automatize the stabilization process > - keep up with upstream or use any other stabilization system > current stabilization system is defined here [2] > and here is the process to stabilize the kernel [3] > As now we are working to automatize the process. > > Please add any other topics, is also possible to discuss directly in > this thread. > > [1] https://doodle.com/poll/6giztg2vuw8wz6kf > [2] https://wiki.gentoo.org/wiki/Project:Kernel#Kernel_stabilization > [3] https://wiki.gentoo.org/wiki/Package_testing#Kernel > I'll add my general availability in a separate thread, as well as confirm via the Doodle - as updating nearly 200 slots is quite a slow process!!
I'd like to discuss the possibility of harmonising the bumping and stabilisation process across the currently maintained source packages, so that, in principle, whilst they may not be fully supported via Security Team (we already have disclaimers for this), users choosing to opt for, eg. ck-sources, would know that because 90% of the code-base has been 'approved' via gentoo-sources (upstream + gentoo patches) that any discrepancy due to failure could be quickly narrowed down to the patchset, and the relevant maintainer can choose to pursue with their specific upstream. The extent to which this is feasible can be debated, but if we can establish a basic procedure that is, eg. automated, perhaps individual maintainers will want to 'pitch in' if the effort required is minimal enough. The objective would be to create a obvious 'choice' of "known-good"ish kernels that any user could choose from, whilst preserving maintainer workflow separation, etc.
signature.asc
Description: OpenPGP digital signature
