-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/31/14, 10:51 AM, Takashi Iwai wrote:
At Thu, 31 Jul 2014 10:32:06 -0400, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi folks -
The openSUSE team recently announced[1] that openSUSE Factory is moving to a rolling development model, similar to how Tumbleweed has functioned for some time. I think this will do wonders for the stability of Factory and hopefully make it interesting again for those of us who used to sync nightly and zypper dup first thing every morning.
It does bring a few questions with it, though. How do we handle the kernel with a rolling release? Having multiple outstanding versions isn't an issue unique to the kernel, but few other projects are as large and have as much churn between releases. The folks trying to support the kernel as best we can are short on time as it is, so I'm concerned about establishing parameters for which bug reports will be considered valid[2]. I'd like to define what those are so that anyone going through bug reports (even someone not actively involved in kernel development or maintenance) and see which ones can be closed or, at least, put on hold until they've been reproduced with the latest version.
1) How do we handle releases of the Factory kernel? 2) What releases will be considered "supported" simultaneously?
For 1), I propose we make it official that Kernel:stable is now the external repository for openSUSE Factory. Even though Factory has already been pulling from Kernel:stable, making it an official thing means that security fixes and other backports are actively added to it rather than it being Jiri's side project. Factory would only contain point releases moving forward and release candidates would be confined to Kernel:HEAD. As a result of the change, I'd start adding -rc1 updates to Kernel:HEAD rather than waiting until -rc2 as I have in the past. It also means that there would no longer be a delay for things like Xen and ARM in Factory.
I'm for Kernel:stable, too. Taking rc kernel doesn't fit with "releases".
As for 2), I'd like to hear suggestions. With only so much time to devote to supporting the Factory kernel, we'll need to find a balance between convenience for users and bugs actually getting fixed. We have options between supporting every release (which I would actively fight) and dropping support for any previous kernel as soon as a new one is added to the repository. I've added some interested parties to the CC list, but I'd like to hear from anyone with an opinion.
We can follow the rule others use, e.g. defining the expiration period when reporter doesn't reproduce the issue with the updated kernel, holding it opened for a certain period (say one month) or after three strikes. After the expiration, close bugs as NORESPONSE (automatically if possible).
Could you elaborate here? When it is it ok to say, "sorry, just use the newer kernel?"
Related to 2, I'd like to put more effort into trimming down the number of patches we carry in the openSUSE kernel. Over the years, we've done a pretty good job of that (compare the number of patches in a SLES release vs openSUSE), but we can do more. SUSE has already hired several engineers to work on getting our divergent Xen implementation into something that is mergeable upstream. Once that happens, the openSUSE kernel patchset should only contain security/stability backports.
I'm pretty optimistic about this. The current amount of patches is already manageable, IMO. But, of course, I'd love to see more reduction there, too.
Where we're at it: what about ABI, e.g. for infamous graphics drivers?
We'd probably freeze it when pulling from the master to the stable branch. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT2lj1AAoJEB57S2MheeWyDGYQAIgXkg2Bp8XhXzvK66K7Tvdv MoNVxWGZtmjC2gBRxVDncLeajzY5Otr3aWgwEW+czBRFaO+IVGtpWNNlvi2zKtSd v4O0783Rtlo+PNbvYf2vbsqGg8FvpCLf42aoTN/adQab4NH+BH4rLdWSUffVcBHi GNThavt9Ib4udc3WN2zwhfve8lwlZl4HOs9a4x5kM5+y7Li/V6ofgIOU7Wx7PmFi W9X1TDyusQlmNz7AailI0LqW4wPF6CWLK3deAYnsNPCCJyxFdDnYpDQVU+nNcoFq Wsyh7RDTioE1NQ8Ui9ixz7ai9rCGTql2kbpFYmTmZK9qcaIc4m8BforK0Go3BHTa 6yQJx56cBpzsWIU0gYKBKqgxoyAN89fOagW90jAyR7s0tN9iM38/n237CT0BEwRs e4fZevt6QV/jX58ADn/f0BP5E0DeGkRnmXLsY97bcjpnQLGd/xoH7b4/Beb5GVo1 3Q/RxXYoF3ZCaEdfAxmV5d6XhZDGPC8IWDmXXGY4c6MQoziiP5MnPr6xCFGBblPH iBYYG+KelOEdvnSvhgEBxWEHqiClcU/cZ8JeMROEkVbIORHmARGZYsu7TPofTKby c3zg2WggrL4v3++WcH+iGkBQtshIYmA2vWDfgDcQdUOMBV51j+oAffz/pCFib34E PwGeBippR8tPT3QYZF9X =rxul -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org