[opensuse-kernel] Factory -> Rolling releases: What does it mean for the kernel package?
-----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. 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. 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. - -Jeff [1] https://news.opensuse.org/2014/07/29/factory-rolling-release/#more-18251 [2] I'll be the first to admit we're open to criticism in how fast openSUSE bugs are handled already - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT2lNmAAoJEB57S2MheeWyBw0P/iwhsLnc9IECJ3dGc6DylTEN M3DCvT5LsWajXZ1PrKpByww4ZeMKCiYKf7Y4Jo6Jd864ipZ5mFGviCkm5x9Q7sI+ 5qX9izy742kdlgQyFM3v+AYqtz+CVlzKwcHa1GTjLq5nOycxr6G6UWw6StD3FVoy r/a1wQUzRj0Y/ypwqtF0F4Mifbt+JATHutDJsfSmbyJlhB8nF+nYCTQKrmDV9zVZ Qekm5zzns4OwG3cL82vp5x1Mj8gr86/TwiO/DY3D7U/Dcv8m7izRLSSpRHkkuKtL VutxMXgbrZ5ga2c8ocatTj1e2Ntw1c8sLCzKJ6ubuXXCBQJ4z3eXQayliHiXExBJ yfThxnK49rD7CNEL6LhKdAaiJFEwudopmy2gEClOQV9xrFhrCBUuM5Ml7VBD2xTD d8k73OgxzpXA3UCwc7omR4DS1I1QfyxQaPRfXFi8kdywWe6gNmkmITst7gAdyjmi XjOM0O9jqBgi6TcXsxF+RiS2vxtR330aZty7VrlCu4+n4jzD4fk0FXL7u7pNmW2D n9/m33yq9cyxUeS3+ERq5hCojztTaqrs9sky1+BwdHeonCBAkpwvCKyoO8FhnM4k fZpF7eVNYBL8TZfhJ4YBXw/TRvWjqataI7RfzLdpiYxuBiluhuRBFJxs5d0t9Na1 vJpQbJP6jRTsuJnA7Zk1 =+cb1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
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).
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? thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----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
At Thu, 31 Jul 2014 10:55:49 -0400, Jeff Mahoney wrote:
-----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?"
IMO, one month would be seen as long enough. Reporter can reopen the bug at any time if it's reproduced with the updated kernel. Or, three strikes, i.e. keep opened for two releases and then close.
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.
kABI is often PITA, and I'm not sure how solid we should keep it. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/31/14, 11:19 AM, Takashi Iwai wrote:
At Thu, 31 Jul 2014 10:55:49 -0400, Jeff Mahoney wrote:
-----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?"
IMO, one month would be seen as long enough. Reporter can reopen the bug at any time if it's reproduced with the updated kernel.
Or, three strikes, i.e. keep opened for two releases and then close.
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.
kABI is often PITA, and I'm not sure how solid we should keep it.
If our only concern is truly just the graphics drivers, we could probably collect the ABI dependencies from them and limit the kABI checker to those interfaces. Otherwise, yeah, the full kABI check is overkill. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT2l7sAAoJEB57S2MheeWyWjAP/Rt6Tx5AvAMsLWdZqH4YcRRu i5UcuD3EcfsevT3QnBF8UqsxHkVvf8kZe1j7lfHkFXjvBvVMdUF49Y0jOZcdTtcO nt4eP15T9GjrzkQkY4GvNOuYO0JfWedIxMVK4WKBDbX2d0doUGoL8n3MxWgYw4ZM PIZHQE4HKoc8JwK7EDcL5WHgwC1Owrpj0gag7Vz+uI44gRHJim+qFwgh8dO7eZxh oTbf7Ts+TnSQAIjQU/EJ8JuzFvUakIF0R43pWA8cdsOwSAMNu7DLOBI+LJGwdhnF PQZMuTHMCivIZU6sDTZJtemXwBR3WIWTL4Zg+ZAWw8yNsJxtQ5ZvlJyZOmJ/CsJ5 ylOYY0fhNSeO4SIZZVYRAwPmEmvba3DC2sXysA7s1FG2FG228Y+4Zb3/NDzKpakD 0mGfkmNDhXk6JIQnm8OgTTYc7ObMoIqt7stjKChVP8EpN5ihQeYZyMKnubtEMAEe wKFEppfpwR/XA6eiWdAbImH7zhxZL+VWRnyVE5wWo9eS6g3nO6c+/cItO2wFJfi4 FAW5VYU8YTGE2y9inAjgXsNiLKuVJ6ilPrl7+JU3Q9WGe7M6uAe9/hmudXvbMvIx PcSvOzo0xMR7eRyAMRrHJ85cy5/ag3ZlRIuDFDECpNPZG7GLff7CW22VzDYVehRU Hwqa0fHLjasui9UCSHg2 =g0F7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Thu, 31 Jul 2014 11:21:17 -0400, Jeff Mahoney wrote:
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.
kABI is often PITA, and I'm not sure how solid we should keep it.
If our only concern is truly just the graphics drivers, we could probably collect the ABI dependencies from them and limit the kABI checker to those interfaces. Otherwise, yeah, the full kABI check is overkill.
The reduced kABI set sounds like a good idea, indeed. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-07-31 16:32, Jeff Mahoney wrote:
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.
OK. I added factory-maintainers to the Kernel:stable project, so that Coolo can pull from there. Or shall I automatically submit new kernels to devel:openSUSE:Factory:kernel?
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.
IMO having bugreportes reproduce with the latest stable kernel is not asking too much. The packages are conveniently available. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-07-31 17:21, Jeff Mahoney wrote:
On 7/31/14, 11:19 AM, Takashi Iwai wrote:
At Thu, 31 Jul 2014 10:55:49 -0400, Jeff Mahoney wrote:
We'd probably freeze it when pulling from the master to the stable branch.
kABI is often PITA, and I'm not sure how solid we should keep it.
If our only concern is truly just the graphics drivers, we could probably collect the ABI dependencies from them and limit the kABI checker to those interfaces. Otherwise, yeah, the full kABI check is overkill.
Agreed. The other KMPs are part of Factory and rebuilt automatically. We just need to keep Kernel:stable and openSUSE:Factory as close as possible. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Thu, 31 Jul 2014 17:29:28 +0200, Michal Marek wrote:
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.
IMO having bugreportes reproduce with the latest stable kernel is not asking too much. The packages are conveniently available.
Right. But now one thing came to my mind: is there any backup of the old released (kernel) packages? For the released products in the past, we keep every updated package. But with a rolling release...? Having the old packages is often really helpful for debugging, it can narrow down the range. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/31/14, 11:32 AM, Takashi Iwai wrote:
At Thu, 31 Jul 2014 17:29:28 +0200, Michal Marek wrote:
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.
IMO having bugreportes reproduce with the latest stable kernel is not asking too much. The packages are conveniently available.
Right. But now one thing came to my mind: is there any backup of the old released (kernel) packages? For the released products in the past, we keep every updated package. But with a rolling release...?
Having the old packages is often really helpful for debugging, it can narrow down the range.
Even more importantly, having old packages is where we get the debuginfo. We'll need to sort that out too. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT2mIHAAoJEB57S2MheeWyNiUQAJZPRShwSQUg9lkEdrLTrkF/ xGGCqNEwVG6zWRzjN+/gVSIBBj04Z93V3ICbuUYMjHe2NhKBRT2dL0pSH9DS0Z8+ wQYuOfQ2vLH9FmfBel1+MKMX+9z1f+AVFcqfHySTldsWLGyI2VqJYl9CE9wRqTDA EOqPmMwO6BEFVgVFFJ/K699JzXe8I3epcK922J63mo7ASzGnOcJRQ8Uvtgp7Aw3C dBpdOoFj7pc7KhqAFPdS9NymukqeZWdmY66vRrfYdu7YZTvEWmDKzTSxJnYB2lVO ZPkThHsq862u+DoKJmsRf+MO7oby+9v9j0zMbKrVtKZ4zAjT5V+65d0iOngiJvzR ZLAwmxp9WuWK32iz9K1PvmZ0R5FOy4ifFQvP+mRY96bu8xhH8rsEl7kIzGcBo14i jKr0+Y12gk3Lzwr7v4fjOjB10YtbWKrSRh/esNjFRMGJj2xPN3nZrc6/y9NFsBUw kjWyojkbssctvC+kGmo+gJ4liU+XJTVAPbCzquqXZdnvMQsevoAzark6DcmvXuyF xttZkyQF19pIqUT7ceeTFImO6vVwgMy3TOYTjGlObJqHLpgmtW5bAihwe8c5n4KU TjMYf7uqEIf01jbbrj9DZR7r82xJObP+sxhqc6qg1UZce5CYzYNB4ou1GlcJb7ig z+UYjplCfoMETER+fFG9 =zSNx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2014-07-31 17:32, Takashi Iwai wrote:
At Thu, 31 Jul 2014 17:29:28 +0200, Michal Marek wrote:
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.
IMO having bugreportes reproduce with the latest stable kernel is not asking too much. The packages are conveniently available.
Right. But now one thing came to my mind: is there any backup of the old released (kernel) packages? For the released products in the past, we keep every updated package. But with a rolling release...?
Having the old packages is often really helpful for debugging, it can narrow down the range.
I've been running a script to keep an archive of the kernels built in the internal buildservice for some time. I just need to export it somehow at least internally. But if the buildservice could do it for the Factory packages, that would be great as well. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 31.07.2014 17:29, schrieb Michal Marek:
OK. I added factory-maintainers to the Kernel:stable project, so that Coolo can pull from there. Or shall I automatically submit new kernels to devel:openSUSE:Factory:kernel?
devel:openSUSE:Factory:kernel is just a workaround for the switch between HEAD and stable. Once stable is settle, we can remove the devel: prj again. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Dne 31.7.2014 18:03, Stephan Kulow napsal(a):
Am 31.07.2014 17:29, schrieb Michal Marek:
OK. I added factory-maintainers to the Kernel:stable project, so that Coolo can pull from there. Or shall I automatically submit new kernels to devel:openSUSE:Factory:kernel?
devel:openSUSE:Factory:kernel is just a workaround for the switch between HEAD and stable.
Once stable is settle, we can remove the devel: prj again.
OK, and shall I then autosubmit kernels from Kernel:stable to openSUSE:Factory? Thanks, Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/31/14, 4:43 PM, Michal Marek wrote:
Dne 31.7.2014 18:03, Stephan Kulow napsal(a):
Am 31.07.2014 17:29, schrieb Michal Marek:
OK. I added factory-maintainers to the Kernel:stable project, so that Coolo can pull from there. Or shall I automatically submit new kernels to devel:openSUSE:Factory:kernel?
devel:openSUSE:Factory:kernel is just a workaround for the switch between HEAD and stable.
Once stable is settle, we can remove the devel: prj again.
OK, and shall I then autosubmit kernels from Kernel:stable to openSUSE:Factory?
That's what I had in mind. We still need to sort out when we pull from master into stable. David Sterba suggested waiting until the first -stable update for the next point release. So, e.g. Factory uses 3.15.X now and we wouldn't move to 3.16 until 3.16.1 was released. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT2qtmAAoJEB57S2MheeWynW8P/0WCdCt+pmU/K99h/Tp/nd3O a2uyy6c96LsUUWSG1bDbrohonkA5mSAvkcppJxh+oneFh4e06XxjMMou3dfWAopr 7OEfS2tKav8hEppAluG+KArWrAk7wkRLLfVNVjIHJUbM6Gd6AJ4w15jw5cC+9PQP kzwnnAWzZyFb6g0wwH+ycni+vxpSe6/lUrvnHKSMSjf9I5HoMq2QNNb1OXjLAmhg F3nCktPmYC0kr25cPHjAMR/Lhk3szsfaJlJgTR7uD3BwEKSBMEIMEiXe9twC4im1 pylzOxUQwa9Xbg978gPz7fNOQ3MySD1T0iA2vm9n6jWBiGwWf7ZS0PG4WzwLcvhZ MyNsubRNX3yotzqzWcDFKpi2kc/O6aaRVSwYhK8QsM2xXIMuSIe4CwQiE0ll2gcp fMP+VS/zZMqdnnEAcint31e4dqF5sEP+x2kYnDNBXh1TACoIj0f16T0A8c83CWA6 Ta+n1lP+MPKed/etrO6PZRSryCEUcoTejYRGg2or7jOYWxtGDCMRmfWQt2s6v3yz A8z/5I3AjuJ/ChwBvRKLog7l+8NOCl9Z0J1fR+QmpqqeS9Ndnfn9Y+iq7r8/LZi/ vJBf3eOiw8YnKM7EfFuX4vZjZyuq6M3kV2gesiZV996K+HLmy+pqlXcCYGlCGR9a RvyiwfwPoEOxkC9ZqXAC =fw9a -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.07.2014 22:47, schrieb Jeff Mahoney:
That's what I had in mind.
We still need to sort out when we pull from master into stable. David Sterba suggested waiting until the first -stable update for the next point release. So, e.g. Factory uses 3.15.X now and we wouldn't move to 3.16 until 3.16.1 was released.
I wouldn't do that. Factory is actually using 3.16.rc7 and beside the mkfs.btrfs OOPS I have no problem with it. I can live well without the RCs in Factory, but I would like to see problems as early as possible - - with the hope someone is actually fixing them too. Greetings, Stephan - -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPbH4YACgkQwFSBhlBjoJYRywCggJJlEgaHwWsTjoY3Xbu4S3P4 HR4AnA8qnTC2cT5L8kvWViBDsHbDx4oJ =aQs2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi Jeff, Le Thursday 31 July 2014 à 16:47 -0400, Jeff Mahoney a écrit :
On 7/31/14, 4:43 PM, Michal Marek wrote:
OK, and shall I then autosubmit kernels from Kernel:stable to openSUSE:Factory?
That's what I had in mind.
We still need to sort out when we pull from master into stable. David Sterba suggested waiting until the first -stable update for the next point release. So, e.g. Factory uses 3.15.X now and we wouldn't move to 3.16 until 3.16.1 was released.
I would start with 3.16.0. Avoiding the .0 because it might not be good enough does not work, if everybody does that then .1 won't be good enough either. My only concern is 3rd party kernel drivers, in my experience it can take some time before they are adjusted to build and work with the most recent kernel. -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/1/14, 1:03 AM, Stephan Kulow wrote:
Am 31.07.2014 22:47, schrieb Jeff Mahoney:
That's what I had in mind.
We still need to sort out when we pull from master into stable. David Sterba suggested waiting until the first -stable update for the next point release. So, e.g. Factory uses 3.15.X now and we wouldn't move to 3.16 until 3.16.1 was released.
I wouldn't do that. Factory is actually using 3.16.rc7 and beside the mkfs.btrfs OOPS I have no problem with it. I can live well without the RCs in Factory, but I would like to see problems as early as possible - with the hope someone is actually fixing them too.
I must be missing the goal of the new rolling update Factory then. My impression was that it was effectively going to be what Tumbleweed has been in the past and that it shouldn't be a dumping ground for prerelease software anymore. Users who want to test an -rcX kernel will still be able to via Kernel:HEAD. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT26RcAAoJEB57S2MheeWyqYIP/0jtVM7K0wHEeK70vqm3e5+3 +P3Yd7bD9Sx6v28jZheP4XyahX60hUSxQb3dcpGDoy9WUhZGsX3klwBE0g69ZZ3X EZGNpBUNvOrZCkUVn6ta4ZdGk8GNuU3bevCBWFvKGApik8XGyReJv6UK5cDxENFO SIVQ9vlVHU2jW42ilaY7mpKbiQJi+wWKSS26YmbImCU+AqEVaEkN7K83QLC0h7G3 qtQKPBsdYx6QYTp5fOQrXgJccMSR7WZzCANRba3vXiOwwOpawaAYu1svjWPXdW+v hekMTLMI/w/epIV6EbFDSuub29P93oY70ToL7S9npisRm95LzSMlR5r4N5bsi0Ca zHJVoqvVqecP3wkaYj7DmmmgUdnWTWJhjtaBWEPBHspP9Le2+dlE8gqD6FbjHWrK Nz35xwDH0kr9l2OeEWD8E9KhlN2TrBau5MBsZGppfQhShvJHlfc/emFO/3cVdakl a6dPaFAuwPfIfCajo7MPXZnWnDM5MGWMbGuMIIahihgeP2tn48ZCAjMInuU36wD5 uLkUfKuBUgdTO9NpBp912BWs8IKjiX6fwKsWm6GXpj8VeFB7bFZTZBanF3fy6OR0 CEH19rhYBop4ucI87PiMjUWjPXt0XeDTfn8wv5CUIfRSiDO1WpWTzokFfARAnmPi 7Wab5NDWsP1njfxF71KG =m07Z -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, Aug 01, 2014 at 07:03:02AM +0200, Stephan Kulow wrote:
That's what I had in mind.
We still need to sort out when we pull from master into stable. David Sterba suggested waiting until the first -stable update for the next point release. So, e.g. Factory uses 3.15.X now and we wouldn't move to 3.16 until 3.16.1 was released.
I wouldn't do that. Factory is actually using 3.16.rc7 and beside the mkfs.btrfs OOPS I have no problem with it. I can live well without the RCs in Factory, but I would like to see problems as early as possible - - with the hope someone is actually fixing them too.
My idea is to be more conservative when the kernel is shipped to large number of users who do just 'zypper dup' and expect it to ~work. I hope that this will improve usability of a rolling distro in the long term People who want to test the .0 release could install from the Kernel:stable repository directly (I'll do that). When I'm aware of potential problems with new kernel, I'm also prepared to do a rollback to the last working kernel: setting up multiversion and keeping multiple kernels installed, bootloader points to the working kernel and I boot-once from the new one should any problems arise during boot. This excercise is natural to me because I work on kernel but I'm not expecting an average Factory user to set this up by default. The bad scenario I'd like to avoid is "I've updated Factory/kernel and it does not boot and I don't have a fallback". After such experience the users may leave Factory or just avoid updating kernel when there is a new release. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 01.08.2014 16:29, schrieb Jeff Mahoney:
I wouldn't do that. Factory is actually using 3.16.rc7 and beside the mkfs.btrfs OOPS I have no problem with it. I can live well without the RCs in Factory, but I would like to see problems as early as possible - with the hope someone is actually fixing them too. I must be missing the goal of the new rolling update Factory then. My impression was that it was effectively going to be what Tumbleweed has been in the past and that it shouldn't be a dumping ground for prerelease software anymore.
Users who want to test an -rcX kernel will still be able to via Kernel:HEAD.
Yes. I was arguing in favor of .0 releases - saying that so far rc7 never caused a problem, .0 releases can't be worse. Greetigns, Stephan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 01.08.2014 18:43, schrieb David Sterba:
My idea is to be more conservative when the kernel is shipped to large number of users who do just 'zypper dup' and expect it to ~work. I hope that this will improve usability of a rolling distro in the long term People who want to test the .0 release could install from the Kernel:stable repository directly (I'll do that). When I'm aware of potential problems with new kernel, I'm also prepared to do a rollback to the last working kernel: setting up multiversion and keeping multiple kernels installed, bootloader points to the working kernel and I boot-once from the new one should any problems arise during boot. This excercise is natural to me because I work on kernel but I'm not expecting an average Factory user to set this up by default. The bad scenario I'd like to avoid is "I've updated Factory/kernel and it does not boot and I don't have a fallback". After such experience the users may leave Factory or just avoid updating kernel when there is a new release.
To avoid that we run > 80 tests on that kernel in openQA before factory is published. And we will add more over time. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/2/14, 7:48 AM, Stephan Kulow wrote:
Am 01.08.2014 16:29, schrieb Jeff Mahoney:
I wouldn't do that. Factory is actually using 3.16.rc7 and beside the mkfs.btrfs OOPS I have no problem with it. I can live well without the RCs in Factory, but I would like to see problems as early as possible - with the hope someone is actually fixing them too. I must be missing the goal of the new rolling update Factory then. My impression was that it was effectively going to be what Tumbleweed has been in the past and that it shouldn't be a dumping ground for prerelease software anymore.
Users who want to test an -rcX kernel will still be able to via Kernel:HEAD.
Yes. I was arguing in favor of .0 releases - saying that so far rc7 never caused a problem, .0 releases can't be worse.
Ok, thanks. Sounds like we're in agreement. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT3P0MAAoJEB57S2MheeWyqJcP/3jFIX+pl1P9fcmeOSydUnbY SxuE/RvX4MHYryWgi//rH5E2wva42HUGAggrL6VNZqFo0dYHYhbBPyX3CXvMyraX ZRmx6grBXL0j4/JMZIHZl8sJL2rYiFn+D/u+NiMxy5EKO+o0a1FfXdxur6apmsqX i6+3fRnJYf49uDZ8t9EwMv+B7x9N0ZuK6iKyAXtxFLSTfNJQV/IOP0PVQm8JgNSP 6DqtL9siPFhOmoDrBvn0+Ue1pVuisMqUfCcFppxAN4vI+mCq4Be/NHNfDtauTImd i0DNajpk44X2uPlBehDt89QAOsCMqPCwMRw4AF6d99Lcj5Tw23hEHfuig+HXDlY9 StrLoMS5P7hxsNobZq+Dyga7XncQub3yitGRLiIU0YzE+vunxHDeuDmgsrR6y74p BlHSXYWh3h0mu5eQc7k9JUabaZVLFoQzYr7EqH1GMH9tZA8OaKLhyfR2F9Dm+0f3 C4dpiEWnZufnCoU1xepriLmnJ6S05dd+arq7DFyaOT6amDggEUcv0d4ghvQ5x14g ONahDIjuLwfK+9LslQ3vgl6yLytkTJsAHC5/+GEOrTCrACXQHMjhvfK36U0Y7NTM aWHLu7QEwW5hJfrq+HOCTORbAi6Jr5Alqnx5UaF1a1hewGHEPSFs9RBmBBC+HeCH lDWbjsKECPxxLxf6Cg1B =8JlT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
David Sterba
This excercise is natural to me because I work on kernel but I'm not expecting an average Factory user to set this up by default.
This is already the default, since 12.3. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 01.08.2014 um 07:03 schrieb Stephan Kulow:
Am 31.07.2014 22:47, schrieb Jeff Mahoney:
That's what I had in mind.
We still need to sort out when we pull from master into stable. David Sterba suggested waiting until the first -stable update for the next point release. So, e.g. Factory uses 3.15.X now and we wouldn't move to 3.16 until 3.16.1 was released.
I wouldn't do that. Factory is actually using 3.16.rc7 and beside the mkfs.btrfs OOPS I have no problem with it. I can live well without the RCs in Factory, but I would like to see problems as early as possible - with the hope someone is actually fixing them too.
Actually if Factory is supposed to be the "rolling release for grandma and grandpa" then the RCs are not supposed to go there. People who want to test them can easily add Kernel:HEAD (like I have done for ages) and get the RCs from there, but still have the option to easily go back to a working kernel. I actually lost that possibility with Factory switching to the unstable kernels lately (my secret trick is that I have kernel-default from Factory and kernel-desktop from Kernel:HEAD, and since I never use "zypper dup" but only "zypper up", they always get updated from their origin repository, so kernel-default was the "stable, working" kernel before) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wednesday 06 of August 2014 09:06:19 Stefan Seyfried wrote:
Am 01.08.2014 um 07:03 schrieb Stephan Kulow:
Am 31.07.2014 22:47, schrieb Jeff Mahoney:
That's what I had in mind.
We still need to sort out when we pull from master into stable. David Sterba suggested waiting until the first -stable update for the next point release. So, e.g. Factory uses 3.15.X now and we wouldn't move to 3.16 until 3.16.1 was released.
I wouldn't do that. Factory is actually using 3.16.rc7 and beside the mkfs.btrfs OOPS I have no problem with it. I can live well without the RCs in Factory, but I would like to see problems as early as possible - with the hope someone is actually fixing them too.
Actually if Factory is supposed to be the "rolling release for grandma and grandpa" then the RCs are not supposed to go there.
As Coolo already explained, this was not meant as a proposal to use RC in Factory but as an argument for moving to next version with 3.x.0 rather than waiting for 3.x.1 Michal Kubeček -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 31.07.2014 22:43, Michal Marek wrote:
Dne 31.7.2014 18:03, Stephan Kulow napsal(a):
Am 31.07.2014 17:29, schrieb Michal Marek:
OK. I added factory-maintainers to the Kernel:stable project, so that Coolo can pull from there. Or shall I automatically submit new kernels to devel:openSUSE:Factory:kernel?
devel:openSUSE:Factory:kernel is just a workaround for the switch between HEAD and stable.
Once stable is settle, we can remove the devel: prj again.
OK, and shall I then autosubmit kernels from Kernel:stable to openSUSE:Factory?
I SRed 3.16.0 from Kernel:HEAD now and also filed a changedevel request to set Kernel:stable as devel prj - once 3.16.0 is either in factory or Kernel:stable, we can approve that and then Kernel:HEAD is purely experimental ;) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/8/14, 7:28 AM, Stephan Kulow wrote:
On 31.07.2014 22:43, Michal Marek wrote:
Dne 31.7.2014 18:03, Stephan Kulow napsal(a):
Am 31.07.2014 17:29, schrieb Michal Marek:
OK. I added factory-maintainers to the Kernel:stable project, so that Coolo can pull from there. Or shall I automatically submit new kernels to devel:openSUSE:Factory:kernel?
devel:openSUSE:Factory:kernel is just a workaround for the switch between HEAD and stable.
Once stable is settle, we can remove the devel: prj again.
OK, and shall I then autosubmit kernels from Kernel:stable to openSUSE:Factory?
I SRed 3.16.0 from Kernel:HEAD now and also filed a changedevel request to set Kernel:stable as devel prj - once 3.16.0 is either in factory or Kernel:stable, we can approve that and then Kernel:HEAD is purely experimental ;)
Thanks, Coolo. Jiri, how do you want to handle the syncing between master and stable in the future? Once -rc1 is released, I'll start merging it into master. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT5OucAAoJEB57S2MheeWyDo4P/1y+gK1TV+377+aX6cX/iiU3 2hBAAF1yy+E87ytaP3imGOEC+SuqWQtln+O1V4JYrqUSLKwr/fqpUMnSxBvOgLcK YVpp8TGaHxiyM5FuwppeX3fLPYeQa9RY/HUzYJUlCeV35Wo/fOKZg3HzM3fYdgxK LsyqhDVMwnRK8uj6pE3i28tDaosk23gFKs9DsquVYbauSY7XhD826p5OmEmyqKuI fubSN3zUASF7D2lAEbEPRE1TJLpjVU2VOUdUnqhxIcttqxyj1HnHuTWFuUVh4iN3 mr1JJIdQ90ApXY8Wb5pOkmO46Vud4AbfEu1fP1PxSLfdu59rtXxMvPHEr7KlBZSu 3HrGT4rp1DrxayEKBXO3WFZiO2mspd2T7Rz4vqJydsSYIekrFGuUMeguialvgWAi 12N0Gbn3IfE9sg7P4jm7itk8qSMRA1drcAQxAdDCFMsjmAvXEuSkBDGqiqe+U7GA 6iFRi9pvQPxTj/chiGyuhR4xXg4kue9yX5GDA5KVduo/grefK267LzoEnNVnNQ7V Nr5Bhf+XKHWP+0ovu/Br4qNMn52pk6guVRhKPvsh6RpEPVXVLBLP3n54z3VJOG7y bnATXUojSX03xylxtRXfQ26c8vSdpbKRhP6YW5dRx07rz3jdATSJUV0viuhoRh1i s7sjAjbSK1m6wxzhkQCZ =q4R5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/08/2014, 05:24 PM, Jeff Mahoney wrote:
I SRed 3.16.0 from Kernel:HEAD now and also filed a changedevel request to set Kernel:stable as devel prj - once 3.16.0 is either in factory or Kernel:stable, we can approve that and then Kernel:HEAD is purely experimental ;)
Kernel:stable is now at 3.16.1. Do you want me to create SRs when we have something new and (hopefully) working?
Jiri, how do you want to handle the syncing between master and stable in the future? Once -rc1 is released, I'll start merging it into master.
I would continue with the current scenario: we start merging master to stable when final version X is put into master, until (X+1)-rc1 is put there. - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT8xXFAAoJEL0lsQQGtHBJ0mAQAJ5nRecNZPRKVzFq6SX5pnac +hhmDzt8vpqoPai0H5VBwDxkrdI04si1yfe7ho1wjKPu6lNkxSIGEtWnxuudcxS/ mirWFByxs1y0M2pYPb1fDeCj4h0Fq1wPCz0RqJKdlvPRmdW9HZ1UGFNJWFi+wIB0 zdUK83teVGNP/hFawdQclU0uUwbThCQbCRFgiFJinkyry5dNC0UfQhuEoGAyy6QI WI19FZqDs8+f7qHXJBWtzvcnD5peDpHvjJIB4qdbJ1bMNBtA0fJNum3ckeSFXsRt 51AlXzBGvkU5GHz11cyWt0kVRWVdtx6cle3/L1H7NWiH6Br8HxFDQ7hwmo+aEVL/ DAY9rRsnqcK9/gULfXUmjrDvekEo5soYMpubPg7rIhNnBi6/igr1kxGtrKz79uxs JUbioWfrvs9tTdkT+ePeXMq8mMYM97pz989X5cd+VvlP1MK2WG4Spt6uNgplEOVX RGrh9+jS6i3eq0nM2M5S92iCIXBikkrD4LspIEPJR/2Bj1Mh2uvqG52700JjW9f5 G9UsmqmMFYSl5sqNY3OfxGo1xC2UNvqmEYdt9Mj50qnR41BfkgYXLTfh2TAl6pMN f/+oUOIxAHa9J1LGAs5COnKhNTmG4YoKXvSjrGndE0T/4Z+uYzf3h8MaC5RF0tyj Iq/uWBV5amnClBT2eA0Y =tIem -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19.08.2014 11:15, Jiri Slaby wrote:
On 08/08/2014, 05:24 PM, Jeff Mahoney wrote:
I SRed 3.16.0 from Kernel:HEAD now and also filed a changedevel request to set Kernel:stable as devel prj - once 3.16.0 is either in factory or Kernel:stable, we can approve that and then Kernel:HEAD is purely experimental ;)
Kernel:stable is now at 3.16.1. Do you want me to create SRs when we have something new and (hopefully) working?
Can this be done please? Right now factory-maintainer script submits the packages and factory-repo-checker script denies them because they don't come from a valid devel project (i.e. one that builds against factory). So either create a new repo or a new project or whatever - but please fix this situation. Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iD8DBQFT/EnYwFSBhlBjoJYRAsCpAJ98wwwPH4zqZOH2muxnzqSEptI/mACg3KhJ AHefsy09FO+/RN32nZDd5qY= =Ib6C -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 08/26/2014, 10:48 AM, Stephan Kulow wrote:
On 19.08.2014 11:15, Jiri Slaby wrote:
On 08/08/2014, 05:24 PM, Jeff Mahoney wrote:
I SRed 3.16.0 from Kernel:HEAD now and also filed a changedevel request to set Kernel:stable as devel prj - once 3.16.0 is either in factory or Kernel:stable, we can approve that and then Kernel:HEAD is purely experimental ;)
Kernel:stable is now at 3.16.1. Do you want me to create SRs when we have something new and (hopefully) working?
Can this be done please? Right now factory-maintainer script submits the packages and factory-repo-checker script denies them because they don't come from a valid devel project (i.e. one that builds against factory).
Provided, we decided the kernel to be the base for the factory, I inclined in the end to switch to build against factory. So I committed that change to the repo and changed that manually in the repo for today. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, Jul 31, 2014 at 10:32:06AM -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,
Does Kernel:stable always follow Linus' tree? Or does it wait and skip?
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.
Would we have packages say on Kernel:HEAD to help folks on Kernel:stable looking for a new driver / fix? By definition Kernel:stable will have to wait until Linus' tree gets a fix merged before it trickles down unless we cherry pick. If we want to reduce work on Kernel:stable having a pointer to Kernel:HEAD rpms could be a way to get issues resolved a bit quicker once submitted. I'm saying we could do that if we wanted to try to reduce work load on factory and take advantage of existing development models which can help users. Otherwise its a bit of work, not a lot, but it is some work.
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.
Can you elaborate on the existing delay for Xen and ARM in existing Factory? Would like to make sure I understand that.
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.
To be clear you are against supporting every release contiguously, so say we 3.17 is released but we were on 3.16.2, we'd immediately phase out 3.16.2 as soon as we release a package for 3.17. This makes perfect sense to me. I'd be nice if we had an option to let users select if they want to opt-in to rc release of packages as that would allow for a streamlined way for users to get test packages being baked, which I suspect will be useful for getting users to test before reporting / following up on a fix. A kind of *self help service*. I wonder if Gentoo has something similar, Vlastimil? This could be a generally useful thing, not just for the kernel. Furthermore if we had an option to use a "vanilla" kernel then we could use the latest and greatest kernel:HEAD with no delta and give users the ability to report directly to kernel.org. That could be another way of *self helping*, and getting folks more engaged upstream.
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.
My goal with xen is to kill any delta other than required backported stuff, and that also should have a respective upstream commit. We already have gobs of stuff we can nuke, so I wonder if testing it out on Kernel:stable would be a good starting point?
- -Jeff
[1] https://news.opensuse.org/2014/07/29/factory-rolling-release/#more-18251 [2] I'll be the first to admit we're open to criticism in how fast openSUSE bugs are handled already
IMHO a rolling release should try to get users more in line with the direct core communities involved to help with considerations on resources on reports. For the kernel I would hope that this would enable a similar approach, we should strive to keep folks engaged upstream and the closer that is to the latest release the easier I think it will be on both us and users. A few points not yet addressed: 3) The kernel is now tied to systemd, so how are we going to pair those up on OpenSUSE Factory? 4) Backports: if a user lacks support for a device driver they typically should be uprading their kernel and if we're on the latest point release that should suffice for many users. For the latest and greatest hardware though, those components might only still be being baked. This may also be true if a series of fixes or enhancements have been made to a device driver but not yet released. This is where the backports project comes in. In terms of reducing effort to deal with issues if a user is using a linux-next backport snapshot and an issue is found they can be sure they can report it upstream to the respective subsystems mailing lists or file a report on kernel.org. The chance of the issue being a backport specific bug if on a recent kernel is extremely low given that backporting consists about less than or = to about 1% of the code used. As I see it moving to a rolling release is a good way to get folks more engaged with their respective upstreams, so any chance at that I think is something we should take advantage of to help reduce our own work load. Enabling use of rc releases of the kernel, specially if they are vanilla, or backports should help with this. Luis -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/11/14, 2:05 PM, Luis R. Rodriguez wrote:
On Thu, Jul 31, 2014 at 10:32:06AM -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,
Does Kernel:stable always follow Linus' tree? Or does it wait and skip?
Kernel:stable is essentially Kernel:HEAD that doesn't follow release candidates. Instead, it follows the -stable branch. So while Kernel:HEAD will occasionally get a x.y.z.1 before an -rc2 is released, Kernel:stable will accumulate stable updates for several months.
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.
Would we have packages say on Kernel:HEAD to help folks on Kernel:stable looking for a new driver / fix? By definition Kernel:stable will have to wait until Linus' tree gets a fix merged before it trickles down unless we cherry
Kernel:stable won't just be a packaged up version of the stable git repository. Fixes would be merged there in the same manner they are in Kernel:HEAD now.
pick. If we want to reduce work on Kernel:stable having a pointer to Kernel:HEAD rpms could be a way to get issues resolved a bit quicker once submitted. I'm saying we could do that if we wanted to try to reduce work load on factory and take advantage of existing development models which can help users. Otherwise its a bit of work, not a lot, but it is some work.
Sure, there's no reason why not. There might be issues introduced by it being a release candidate, but if we can focus on one aspect even in the face of other problems, it could work.
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.
Can you elaborate on the existing delay for Xen and ARM in existing Factory? Would like to make sure I understand that.
The existing delay is because I defer porting of the Xen patches to the Xen team (typically Jan Beulich) and defer changing the configs for the ARM architecture to the ARM maintainers because they tend to be pretty specific to a particular board and I don't want to accidentally introduce bloat that only gets discovered later when someone wonders why the kernel has grown.
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.
To be clear you are against supporting every release contiguously, so say we 3.17 is released but we were on 3.16.2, we'd immediately phase out 3.16.2 as soon as we release a package for 3.17.
Yes.
This makes perfect sense to me. I'd be nice if we had an option to let users select if they want to opt-in to rc release of packages as that would allow for a streamlined way for users to get test packages being baked, which I suspect will be useful for getting users to test before reporting / following up on a fix. A kind of *self help service*. I wonder if Gentoo has something similar, Vlastimil? This could be a generally useful thing, not just for the kernel. Furthermore if we had an option to use a "vanilla" kernel then we could use the latest and greatest kernel:HEAD with no delta and give users the ability to report directly to kernel.org. That could be another way of *self helping*, and getting folks more engaged upstream.
That opt-in is adding the Kernel:HEAD OBS project repository. We also do have a -vanilla option: The kernel-vanilla package. These are tools we already use as part of the triage process.
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.
My goal with xen is to kill any delta other than required backported stuff, and that also should have a respective upstream commit. We already have gobs of stuff we can nuke, so I wonder if testing it out on Kernel:stable would be a good starting point?
Yeah, absolutely. The usual caveat about maintaining compatibility applies, of course. - -Jeff
- -Jeff
[1] https://news.opensuse.org/2014/07/29/factory-rolling-release/#more-18251
[2] I'll be the first to admit we're open to criticism in how fast
openSUSE bugs are handled already
IMHO a rolling release should try to get users more in line with the direct core communities involved to help with considerations on resources on reports. For the kernel I would hope that this would enable a similar approach, we should strive to keep folks engaged upstream and the closer that is to the latest release the easier I think it will be on both us and users.
A few points not yet addressed:
3) The kernel is now tied to systemd, so how are we going to pair those up on OpenSUSE Factory?
4) Backports: if a user lacks support for a device driver they typically should be uprading their kernel and if we're on the latest point release that should suffice for many users. For the latest and greatest hardware though, those components might only still be being baked. This may also be true if a series of fixes or enhancements have been made to a device driver but not yet released. This is where the backports project comes in. In terms of reducing effort to deal with issues if a user is using a linux-next backport snapshot and an issue is found they can be sure they can report it upstream to the respective subsystems mailing lists or file a report on kernel.org. The chance of the issue being a backport specific bug if on a recent kernel is extremely low given that backporting consists about less than or = to about 1% of the code used.
As I see it moving to a rolling release is a good way to get folks more engaged with their respective upstreams, so any chance at that I think is something we should take advantage of to help reduce our own work load. Enabling use of rc releases of the kernel, specially if they are vanilla, or backports should help with this.
Luis
- -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJUEedpAAoJEB57S2MheeWyNx0P/3KAHmTIrL+y0o652OG1ACPK xu1RNsqUG6c17vIgqjP339N4BmrGlmqrrNIQnvSytEHA1yfKfxfaGjwEzDAsFSgq Du4aHcw1aSKecuorJPL+PcNqd08bnZzhWYbIFIdi49R6or1Mx+0y0R/shOlCjkiq q3J2/FjUbSQVfqypQvushRwHFlqfKf8Gs3wQwxwgIPokQdVQbq/2uLNa6FaeuRjm SrFFeleU09jBPwZriNrTw58/pP7WFE3M/f+9Aws0FL69Bs6qXgpzlH5ntRiU5x3Q fQpzMMKne6W+byqsnQ8hskIFhJm2CDNnk/5kvVuW1TwJ1FTB6rpmZRSQ33Fgk7dN x3Tlcq/jXgfO66yE7MycXUpFWOjaUN2+s2BgnllLecWvADapQ6TN535NdCuKUeLq tm0+C5hza1UxdYDGQzP/H3k1hYERk0dGrVwk3X6FcWpgB86YObKwNVn6cV/WpBB/ HLwQJprTGX6yfMtqMeTuORS69XyfxMQKYkaHdoFS6vI0e+gJM3DtbHCWGxdbpwQ5 xOPrFG5HrVK7YdEg5dEA1oU1bjvl7lucMuiZ1suLe6DuGxynECWX9nvYbNOiM27/ y1MZ6mdc96YQrHT8BATK6zjd2u543UoW+Mp+SChXKehGtfrOS997N0hMSH81xGP4 5Y6gWtiHwIXq4Vm26MId =QLjD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (11)
-
Andreas Schwab -
David Sterba -
Jean Delvare -
Jeff Mahoney -
Jiri Slaby -
Luis R. Rodriguez -
Michal Kubecek -
Michal Marek -
Stefan Seyfried -
Stephan Kulow -
Takashi Iwai