[opensuse-factory] How Leap and SLE's timetable overlap
In another thread, Yamaban brainstormed the following kind of schedule for future Leap/SLE releases On 25 May 2016 at 00:20, Yamaban <foerster@lisas.de> wrote:
In light of the LTS kernel the only thing would be to move the release date of Leap / SLE, e.g.
- Kernel in January / settling in Tumbleweed
- Leap first Alpha in late February / early March
- Leap first Beta mid/late April
- SLE (sp) first Alpha early May
- Leap freeze late May
- SLE (sp) first Beta mid June
- Leap last full patch pull-in / first RC mid/late June
- SLE (sp) freeze early July / or better mid August
- Leap release mid/late July
- SLE (sp) last full patch pull-in / first RC early / mid September
- SLE (sp) release early / mid October
I want to compare that to where we are right now with SLE 12 SP2 and Leap 42.2 * Kernel in January / settling in Tumbleweed * SLE 12 SP2 Alphas in Q1 2016 * SLE 12 SP2 Beta started late May <- NOTE: Leap 42.2 Development cannot start in earnest until SLE sources are available, and SLE sources cannot be available until Beta * Leap 42.2 first Alpha TODAY <- THIS IS WHERE WE ARE :) * Leap Alphas & SLE Betas over the next few months (aka 'Q2') * Leap Betas & SLE RC's after that (aka 'Q3') * SLE 12 SP2 Release in 'Q4' * Leap RC's in late Sept/October * Leap 42.2 Release in November Benefits of this current approach over what Yamaban proposed (Leap & SLE interleaved) 1. Leap release is still in November, which in 10 years of openSUSE releases we've proven that releases at that time for year works for us - Winter/Spring releases get too disrupted by Christmas, Summer releases get disrupted by summer holidays. October/November is the time that works for us best. 2. There is a nice symmetry of what we are doing with Leap and what SUSE are doing with SLE. Our major milestones are aligned. Developers working on SLE are directly benefiting Leap and visa versa 3. This timeline has the possibility for stuff like SUSE QA engineers actually working on Leap when SLE development is wrapping up but Leap will be at the prime interesting time of RC's and GMC. 4. We'll avoid the situation we had with 42.1 (where Leap released a few weeks before SLE 12 SP1) and then we had a pretty huge 'mega update' to sync up Leap 42.1 with the SLE 12 SP1 shared packages 5. It accepts the reality that Leap is a fair bit bigger (in terms of package numbers) than SLE - I think Yamabans suggested timeline is a little too aggressive. Even if we could realistically start Leap development before our base system had even started to come together, trying to properly integrate our 8000+ source packages in that kind of timescale is pretty much impossible. Downsides of the Yamaban proposed approach (the "Leap before SLE" schedule) 1. Um..actually I'm no sure there is any benefit..a July release is pretty much impossible when most of the community goes on vacation over summer..releasing that much earlier than SLE means we'll have to miss out on a whole bunch of stuff or have a rough few months keeping everything in sync as SLE comes together..yeah..um..sorry I WANTED to try and write a balanced approach but I think our current roadmap is the absolute best plan we can have given our desire to release something annually and with what SUSE are planning for SLE 12 SP2 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, May 24, 2016 at 6:38 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:
In another thread, Yamaban brainstormed the following kind of schedule for future Leap/SLE releases
On 25 May 2016 at 00:20, Yamaban <foerster@lisas.de> wrote:
In light of the LTS kernel the only thing would be to move the release date of Leap / SLE, e.g.
- Kernel in January / settling in Tumbleweed
- Leap first Alpha in late February / early March
- Leap first Beta mid/late April
- SLE (sp) first Alpha early May
- Leap freeze late May
- SLE (sp) first Beta mid June
- Leap last full patch pull-in / first RC mid/late June
- SLE (sp) freeze early July / or better mid August
- Leap release mid/late July
- SLE (sp) last full patch pull-in / first RC early / mid September
- SLE (sp) release early / mid October
I want to compare that to where we are right now with SLE 12 SP2 and Leap 42.2
- Kernel in January / settling in Tumbleweed
- SLE 12 SP2 Alphas in Q1 2016
- SLE 12 SP2 Beta started late May <- NOTE: Leap 42.2 Development cannot start in earnest until SLE sources are available, and SLE sources cannot be available until Beta
- Leap 42.2 first Alpha TODAY <- THIS IS WHERE WE ARE :)
- Leap Alphas & SLE Betas over the next few months (aka 'Q2')
- Leap Betas & SLE RC's after that (aka 'Q3')
- SLE 12 SP2 Release in 'Q4'
- Leap RC's in late Sept/October
- Leap 42.2 Release in November
Benefits of this current approach over what Yamaban proposed (Leap & SLE interleaved)
- Leap release is still in November, which in 10 years of openSUSE releases we've proven that releases at that time for year works for us
- Winter/Spring releases get too disrupted by Christmas, Summer releases get disrupted by summer holidays. October/November is the time that works for us best.
- There is a nice symmetry of what we are doing with Leap and what SUSE are doing with SLE. Our major milestones are aligned. Developers working on SLE are directly benefiting Leap and visa versa
- This timeline has the possibility for stuff like SUSE QA engineers actually working on Leap when SLE development is wrapping up but Leap will be at the prime interesting time of RC's and GMC.
- We'll avoid the situation we had with 42.1 (where Leap released a few weeks before SLE 12 SP1) and then we had a pretty huge 'mega update' to sync up Leap 42.1 with the SLE 12 SP1 shared packages
- It accepts the reality that Leap is a fair bit bigger (in terms of package numbers) than SLE - I think Yamabans suggested timeline is a little too aggressive. Even if we could realistically start Leap development before our base system had even started to come together, trying to properly integrate our 8000+ source packages in that kind of timescale is pretty much impossible.
Downsides of the Yamaban proposed approach (the "Leap before SLE" schedule)
Um..actually I'm no sure there is any benefit..a July release is pretty much impossible when most of the community goes on vacation over summer..releasing that much earlier than SLE means we'll have to miss out on a whole bunch of stuff or have a rough few months keeping everything in sync as SLE comes together..yeah..um..sorry I WANTED to try and write a balanced approach but I think our current roadmap is the absolute best plan we can have given our desire to release something annually and with what SUSE are planning for SLE 12 SP2
I'm pretty much in agreement that accelerating 42.2 release schedule makes little sense.. But, we all know that one of the major issues for the whole Leap concept was the SLE kernel was too old, so it was decided with 42.1 to use the most recent LTS kernel at the time of release. The newly decided kernel LTS release schedule is to do a LTS release early each year. This year it is the 4.4 kernel released Jan 10, 2016. It will be roughly 10 months old when Leap 42.2 is released. I don't have a solution, but I personally find that contradictory to expectations for a Leap kernel. Brainstorming below: My thoughts as to options are: 1) delay the full Leap release until early year so the yearly LTS kernel can be incorporated I could live with that but I don't like it. 2) Maintain the Nov 42.2 release date, but do a 42.2 "advanced kernel" release 6 months after 42.2 is released that updates the kernel to the 2017 LTS kernel ---> Note that the 42.1 kernel is scheduled to go out of support 6 months after 42.2 is released ---> Note that if SLE is going to do a summer 2017 SP, then having the kernel released into Leap 3 to 6 months earlier will allow them to get useful wide scale testing in advance. More brainstorming: if the kernel team is willing to support 2 kernels simultaneously (as they have done for the last decade plus), then we could have: - Every Fall do a a full Leap release, but based on the roughly 10 month old LTS kernel of the year. Have the fall Leap kernel supported for exactly 12 months after the fall Leap version is released. - Every Spring do a "advanced Kernel" release based on the annual LTS kernel. Support the "advanced kernel" for the last 12 months of that Leap version's support. - During the last 6 months of each Leap version's support, only support the Advance LTS kernel released in the spring after the initial release. Thus: Nov 2016 - Release Leap 42.2 with 4.4 kernel Spring 2017 - Release the Leap 42.2 "advanced kernel" (ie. the 2017 LTS kernel). Fall 2017 - Release Leap 42.3 with the 2017 LTS kernel (no longer designated advanced). Fall 2017 - Drop all support for the 4.4 kernel when Leap 42.3 is released Spring 2018 - Release the 42.3 "advanced kernel" (ie. the 2018 LTS kernel) Spring 2018 - Drop 2017 LTS kernel support (when Leap 42.2 support is dropped). The end result is that over the summer 2 kernels are supported: the current LTS kernel and the previous year's LTS kernel. But during the winter only one kernel is supported.
From the kernel team's perspective they may even be able to leverage SLE kernel support at all times because they will have to support SLE kernels longer than the 12 months I'm proposing. That assumes the SLE will be supporting each of the annual LTS kernels.
Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Sent from my iPad
On 25 May 2016, at 01:24, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Tue, May 24, 2016 at 6:38 PM, Richard Brown <RBrownCCB@opensuse.org> wrote: In another thread, Yamaban brainstormed the following kind of schedule for future Leap/SLE releases
On 25 May 2016 at 00:20, Yamaban <foerster@lisas.de> wrote:
In light of the LTS kernel the only thing would be to move the release date of Leap / SLE, e.g.
- Kernel in January / settling in Tumbleweed
- Leap first Alpha in late February / early March
- Leap first Beta mid/late April
- SLE (sp) first Alpha early May
- Leap freeze late May
- SLE (sp) first Beta mid June
- Leap last full patch pull-in / first RC mid/late June
- SLE (sp) freeze early July / or better mid August
- Leap release mid/late July
- SLE (sp) last full patch pull-in / first RC early / mid September
- SLE (sp) release early / mid October
I want to compare that to where we are right now with SLE 12 SP2 and Leap 42.2
- Kernel in January / settling in Tumbleweed
- SLE 12 SP2 Alphas in Q1 2016
- SLE 12 SP2 Beta started late May <- NOTE: Leap 42.2 Development cannot start in earnest until SLE sources are available, and SLE sources cannot be available until Beta
- Leap 42.2 first Alpha TODAY <- THIS IS WHERE WE ARE :)
- Leap Alphas & SLE Betas over the next few months (aka 'Q2')
- Leap Betas & SLE RC's after that (aka 'Q3')
- SLE 12 SP2 Release in 'Q4'
- Leap RC's in late Sept/October
- Leap 42.2 Release in November
Benefits of this current approach over what Yamaban proposed (Leap & SLE interleaved)
- Leap release is still in November, which in 10 years of openSUSE releases we've proven that releases at that time for year works for us
- Winter/Spring releases get too disrupted by Christmas, Summer releases get disrupted by summer holidays. October/November is the time that works for us best.
- There is a nice symmetry of what we are doing with Leap and what SUSE are doing with SLE. Our major milestones are aligned. Developers working on SLE are directly benefiting Leap and visa versa
- This timeline has the possibility for stuff like SUSE QA engineers actually working on Leap when SLE development is wrapping up but Leap will be at the prime interesting time of RC's and GMC.
- We'll avoid the situation we had with 42.1 (where Leap released a few weeks before SLE 12 SP1) and then we had a pretty huge 'mega update' to sync up Leap 42.1 with the SLE 12 SP1 shared packages
- It accepts the reality that Leap is a fair bit bigger (in terms of package numbers) than SLE - I think Yamabans suggested timeline is a little too aggressive. Even if we could realistically start Leap development before our base system had even started to come together, trying to properly integrate our 8000+ source packages in that kind of timescale is pretty much impossible.
Downsides of the Yamaban proposed approach (the "Leap before SLE" schedule)
Um..actually I'm no sure there is any benefit..a July release is pretty much impossible when most of the community goes on vacation over summer..releasing that much earlier than SLE means we'll have to miss out on a whole bunch of stuff or have a rough few months keeping everything in sync as SLE comes together..yeah..um..sorry I WANTED to try and write a balanced approach but I think our current roadmap is the absolute best plan we can have given our desire to release something annually and with what SUSE are planning for SLE 12 SP2
I'm pretty much in agreement that accelerating 42.2 release schedule makes little sense..
But, we all know that one of the major issues for the whole Leap concept was the SLE kernel was too old, so it was decided with 42.1 to use the most recent LTS kernel at the time of release.
The newly decided kernel LTS release schedule is to do a LTS release early each year. This year it is the 4.4 kernel released Jan 10, 2016. It will be roughly 10 months old when Leap 42.2 is released.
I don't have a solution, but I personally find that contradictory to expectations for a Leap kernel.
Brainstorming below:
My thoughts as to options are:
- delay the full Leap release until early year so the yearly LTS kernel can be incorporated
I could live with that but I don't like it.
- Maintain the Nov 42.2 release date, but do a 42.2 "advanced kernel" release 6 months after 42.2 is released that updates the kernel to the 2017 LTS kernel
---> Note that the 42.1 kernel is scheduled to go out of support 6 months after 42.2 is released
---> Note that if SLE is going to do a summer 2017 SP, then having the kernel released into Leap 3 to 6 months earlier will allow them to get useful wide scale testing in advance.
More brainstorming:
if the kernel team is willing to support 2 kernels simultaneously (as they have done for the last decade plus), then we could have:
Every Fall do a a full Leap release, but based on the roughly 10 month old LTS kernel of the year. Have the fall Leap kernel supported for exactly 12 months after the fall Leap version is released.
Every Spring do a "advanced Kernel" release based on the annual LTS kernel. Support the "advanced kernel" for the last 12 months of that Leap version's support.
During the last 6 months of each Leap version's support, only support the Advance LTS kernel released in the spring after the initial release.
Thus:
Nov 2016 - Release Leap 42.2 with 4.4 kernel
Spring 2017 - Release the Leap 42.2 "advanced kernel" (ie. the 2017 LTS kernel).
Fall 2017 - Release Leap 42.3 with the 2017 LTS kernel (no longer designated advanced).
Fall 2017 - Drop all support for the 4.4 kernel when Leap 42.3 is released
Spring 2018 - Release the 42.3 "advanced kernel" (ie. the 2018 LTS kernel)
Spring 2018 - Drop 2017 LTS kernel support (when Leap 42.2 support is dropped).
The end result is that over the summer 2 kernels are supported: the current LTS kernel and the previous year's LTS kernel.
But during the winter only one kernel is supported.
From the kernel team's perspective they may even be able to leverage SLE kernel support at all times because they will have to support SLE kernels longer than the 12 months I'm proposing. That assumes the SLE will be supporting each of the annual LTS kernels.
Greg, please consider the user impact of what you are proposing. Two kernels in the same distro? Users having to switch to one during the lifecycle of the distro? That complexity and that forced changing brings with it risk - new kernels break things for some people. Some people don't want to take those risks. Those are the people we make Leap for. Leap is never going to support the latest and greatest hardware. It's not meant to. It's meant to be a reliable, dependable, workhorse of a distribution that people can put their faith into. A more moderate pace of change,like the one we currently have, is the best way to accomplish that. For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed. You cannot have it both ways. If you want to leave life on the edge, and your hardware purchases suggest you do, then Tumbleweed is the best platform for you. And before you argue '3.1 Gen 2 is going to take over the world in 12 months, I'd like to point out that USB 3 came out in 2008 and took years before becoming ubiquitous. 3.1 is only just now appearing on new mainstream machines and even then that is Gen 1, fully supported stuff I can find ONE motherboard, a high end MSI gaming board with a Gen 2 card in it We're not building Leap to cover every edge case. USB 3.1 Gen 2 is an edge case now, it will be in November, and I do not feel it's support is a compelling argument for playing loose and risk with the entire concept and purpose of what we're doing with Leap. Sorry-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown <ilmehtar@gmail.com> writes:
For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed.
Or they can use Kernel:stable on top of Leap, which combines the stability with extra hardware support. 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andreas Schwab wrote:
Richard Brown <ilmehtar@gmail.com> writes:
For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed. Or they can use Kernel:stable on top of Leap, which combines the stability with extra hardware support. This is a good point. Personally I often see in forums like "Linux statt Windows" ("Linux instead of Windows", a forum where absolute Linux newbies meet more experienced users) that beginners have two big questions:
* Which distribution supports my brand-new hardware? (Okay, some users also begin with old hardware, but they haven't the described problem.) * Why does my XYZ component not work with the distribution recommended for Newbies? Tumbleweed is not the best choice for newbies. Leap with Kernel_stable is acceptable, but also not so newbie friendly. I would suggest a special download option: openSUSE Leap with updated hardware support (mainly a Kernel from Kernel_stable; but optional also an updated graphical subsystem etc.). A problem with the Kernel_stable kernels is sometimes, that the commercial graphics drivers are not compatible. Currently we have this with the recommended NVidia driver 361.42 and kernel 4.6. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-05-25 13:24, Bjoern Voigt wrote:
Andreas Schwab wrote:
Richard Brown <ilmehtar@gmail.com> writes:
For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed. Or they can use Kernel:stable on top of Leap, which combines the stability with extra hardware support. This is a good point.
Indeed it is :-)
I would suggest a special download option: openSUSE Leap with updated hardware support (mainly a Kernel from Kernel_stable; but optional also an updated graphical subsystem etc.).
I like the idea. Distribute Leap with an LTS kernel, and provide an option to upgrade to a more recent kernel for those that need that hardware support. On "as is" basis, not full support, but neither "kernel of the day".
A problem with the Kernel_stable kernels is sometimes, that the commercial graphics drivers are not compatible. Currently we have this with the recommended NVidia driver 361.42 and kernel 4.6.
If the optional kernel remains the same version for a longish period maybe the rpm could be provided for it. Else, you need the .run package instead. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On středa 25. května 2016 14:07 Carlos E. R. wrote:
On 2016-05-25 13:24, Bjoern Voigt wrote:
Andreas Schwab wrote:
Richard Brown <ilmehtar@gmail.com> writes:
For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed.
Or they can use Kernel:stable on top of Leap, which combines the stability with extra hardware support.
This is a good point.
Indeed it is :-)
I would suggest a special download option: openSUSE Leap with updated hardware support (mainly a Kernel from Kernel_stable; but optional also an updated graphical subsystem etc.).
I like the idea. Distribute Leap with an LTS kernel, and provide an option to upgrade to a more recent kernel for those that need that hardware support. On "as is" basis, not full support, but neither "kernel of the day".
All you need for that is to find someone who will take care of such kernel branch and update it; the infrastructure exists and is publicly available; kernel-source git has script to export the package exactly in the form needed for OBS and OBS will provide you a repository you can simply add with "zypper ar". And now for the hard part: who is going to be that someone? Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, May 25, 2016 at 5:38 AM, Andreas Schwab <schwab@suse.de> wrote:
Richard Brown <ilmehtar@gmail.com> writes:
For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed.
Or they can use Kernel:stable on top of Leap, which combines the stability with extra hardware support.
Even kernel stable is moving much faster than my proposal. Is it reasonable to ask for a Kernel:LTS repo to be created? If it existed back in Jan 2016, it could have been populated with 4.4 then and "early" adopters of the Leap 42.2 kernel could have started to test it. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, May 25, 2016 at 06:02:20PM -0400, Greg Freemyer wrote:
On Wed, May 25, 2016 at 5:38 AM, Andreas Schwab <schwab@suse.de> wrote:
Richard Brown <ilmehtar@gmail.com> writes:
For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed.
Or they can use Kernel:stable on top of Leap, which combines the stability with extra hardware support.
Even kernel stable is moving much faster than my proposal.
Is it reasonable to ask for a Kernel:LTS repo to be created?
As I said yesterday in my response to Carlos, it's not a technical problem, the infrastructure exists and virtually anyone can do it. After all, the kernel intended for Evergreen 13.1 lived in my home project for over a year and some people were happily using it from there. And I believe if such kernel branch is well maintained, its OBS project might be even given some nicer name. So IMHO the real problem of what you are asking is not a repository but someone to prepare the kernel branch and - even more important - maintain it for its whole lifetime. Unless I misunderstood you and you meant to volunteer to do the work, rather than requesting it from poor old Mr. Someone Else.
If it existed back in Jan 2016, it could have been populated with 4.4 then and "early" adopters of the Leap 42.2 kernel could have started to test it.
Looks like another mail of mine went unnoticed... What would you get this way would be very different from openSUSE-42.2 kernel we have now. There is a big difference between just basing on an upstream LTS and basing on a maintained SLE kernel. (I'm not looking forward to the discussions about Leap 42.3 kernel where this is likely to become a real dilemma.) Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, May 26, 2016 at 1:42 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
On Wed, May 25, 2016 at 06:02:20PM -0400, Greg Freemyer wrote:
On Wed, May 25, 2016 at 5:38 AM, Andreas Schwab <schwab@suse.de> wrote:
Richard Brown <ilmehtar@gmail.com> writes:
For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed.
Or they can use Kernel:stable on top of Leap, which combines the stability with extra hardware support.
Even kernel stable is moving much faster than my proposal.
Is it reasonable to ask for a Kernel:LTS repo to be created?
As I said yesterday in my response to Carlos, it's not a technical problem, the infrastructure exists and virtually anyone can do it. After all, the kernel intended for Evergreen 13.1 lived in my home project for over a year and some people were happily using it from there. And I believe if such kernel branch is well maintained, its OBS project might be even given some nicer name.
So IMHO the real problem of what you are asking is not a repository but someone to prepare the kernel branch and - even more important - maintain it for its whole lifetime. Unless I misunderstood you and you meant to volunteer to do the work, rather than requesting it from poor old Mr. Someone Else.
For the next 6 months, the effort involves a single 5 minute effort to branch the appropriate SLE 12 SP2 or Leap 42.2 Kernel repo to Kernel:LTS As those kernel repos are maintained, the Kernel:LTS repo would automatically be maintained. Thus no other work in 2016.
If it existed back in Jan 2016, it could have been populated with 4.4 then and "early" adopters of the Leap 42.2 kernel could have started to test it.
Looks like another mail of mine went unnoticed... What would you get this way would be very different from openSUSE-42.2 kernel we have now. There is a big difference between just basing on an upstream LTS and basing on a maintained SLE kernel. (I'm not looking forward to the discussions about Leap 42.3 kernel where this is likely to become a real dilemma.)
It is precisely the 42.3 kernel that I'm hoping we can start to layout a plan for. In Q1 2017, the 2017 LTS kernel should be published by kernel.org. It will soon find its way into Kernel:Stable. A couple months later 2017 LTS+1 will be published. That too will make its way into Kernel:Stable. If Kernel:LTS exists, then during the couple months that 2017 LTS is in Kernel:Stable, I'm asking that a SR from Kernel:Stable to Kernel:LTS be made. All of the above is straight forward and if I had permissions I could easily do it. (And I'm willing to do it if asked, but I think the permissions issue is more work than the occasional SR). But, as you note the big question then becomes what happens to Kernel:LTS once the 2017 LTS kernel is in it. - On one hand: the SLE team has already said they are not planning to release a SLE Kernel based on the 2017 LTS kernel so they won't necessarily be maintaining it. - On the other hand: the method of choosing the Leap 42.1 kernel was to use the most recent LTS kernel. If that is also the decision for Leap 42.3, then the 2017 LTS kernel will be the Leap 42.3 kernel. Therefore Kernel:LTS will by default become the Devel Project for the Leap 42.3 kernel. Even if the 2017 LTS kernel does not find its way into either SLE or Leap 42.3, I think it is beneficial to the openSUSE community to maintain a Kernel:LTS repo. It just may be that it doesn't get a lot of support except by importing updates from kernel.org.
Michal Kubeček
Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26 May 2016 at 19:11, Greg Freemyer <greg.freemyer@gmail.com> wrote:
Even if the 2017 LTS kernel does not find its way into either SLE or Leap 42.3, I think it is beneficial to the openSUSE community to maintain a Kernel:LTS repo. It just may be that it doesn't get a lot of support except by importing updates from kernel.org.
Then as Michal very strongly hinted already, my advice to you is to just do it. Do it in your home: project, prove that it can be done, prove that you are willing to maintain it, and prove that people want to use it. Then once it has planted it's roots, we can worry about creating a new repo in the Kernel: project An idea like this needs to walk before it can run. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/25/2016 08:54 AM, Greg Freemyer wrote:
On Tue, May 24, 2016 at 6:38 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:
In another thread, Yamaban brainstormed the following kind of schedule for future Leap/SLE releases
On 25 May 2016 at 00:20, Yamaban <foerster@lisas.de> wrote:
In light of the LTS kernel the only thing would be to move the release date of Leap / SLE, e.g.
- Kernel in January / settling in Tumbleweed
- Leap first Alpha in late February / early March
- Leap first Beta mid/late April
- SLE (sp) first Alpha early May
- Leap freeze late May
- SLE (sp) first Beta mid June
- Leap last full patch pull-in / first RC mid/late June
- SLE (sp) freeze early July / or better mid August
- Leap release mid/late July
- SLE (sp) last full patch pull-in / first RC early / mid September
- SLE (sp) release early / mid October
I want to compare that to where we are right now with SLE 12 SP2 and Leap 42.2
- Kernel in January / settling in Tumbleweed
- SLE 12 SP2 Alphas in Q1 2016
- SLE 12 SP2 Beta started late May <- NOTE: Leap 42.2 Development cannot start in earnest until SLE sources are available, and SLE sources cannot be available until Beta
- Leap 42.2 first Alpha TODAY <- THIS IS WHERE WE ARE :)
- Leap Alphas & SLE Betas over the next few months (aka 'Q2')
- Leap Betas & SLE RC's after that (aka 'Q3')
- SLE 12 SP2 Release in 'Q4'
- Leap RC's in late Sept/October
- Leap 42.2 Release in November
Benefits of this current approach over what Yamaban proposed (Leap & SLE interleaved)
- Leap release is still in November, which in 10 years of openSUSE releases we've proven that releases at that time for year works for us
- Winter/Spring releases get too disrupted by Christmas, Summer releases get disrupted by summer holidays. October/November is the time that works for us best.
- There is a nice symmetry of what we are doing with Leap and what SUSE are doing with SLE. Our major milestones are aligned. Developers working on SLE are directly benefiting Leap and visa versa
- This timeline has the possibility for stuff like SUSE QA engineers actually working on Leap when SLE development is wrapping up but Leap will be at the prime interesting time of RC's and GMC.
- We'll avoid the situation we had with 42.1 (where Leap released a few weeks before SLE 12 SP1) and then we had a pretty huge 'mega update' to sync up Leap 42.1 with the SLE 12 SP1 shared packages
- It accepts the reality that Leap is a fair bit bigger (in terms of package numbers) than SLE - I think Yamabans suggested timeline is a little too aggressive. Even if we could realistically start Leap development before our base system had even started to come together, trying to properly integrate our 8000+ source packages in that kind of timescale is pretty much impossible.
Downsides of the Yamaban proposed approach (the "Leap before SLE" schedule)
Um..actually I'm no sure there is any benefit..a July release is pretty much impossible when most of the community goes on vacation over summer..releasing that much earlier than SLE means we'll have to miss out on a whole bunch of stuff or have a rough few months keeping everything in sync as SLE comes together..yeah..um..sorry I WANTED to try and write a balanced approach but I think our current roadmap is the absolute best plan we can have given our desire to release something annually and with what SUSE are planning for SLE 12 SP2
I'm pretty much in agreement that accelerating 42.2 release schedule makes little sense..
But, we all know that one of the major issues for the whole Leap concept was the SLE kernel was too old, so it was decided with 42.1 to use the most recent LTS kernel at the time of release.
The newly decided kernel LTS release schedule is to do a LTS release early each year. This year it is the 4.4 kernel released Jan 10, 2016. It will be roughly 10 months old when Leap 42.2 is released.
I don't have a solution, but I personally find that contradictory to expectations for a Leap kernel.
Brainstorming below:
My thoughts as to options are:
- delay the full Leap release until early year so the yearly LTS kernel can be incorporated
I could live with that but I don't like it.
- Maintain the Nov 42.2 release date, but do a 42.2 "advanced kernel" release 6 months after 42.2 is released that updates the kernel to the 2017 LTS kernel
---> Note that the 42.1 kernel is scheduled to go out of support 6 months after 42.2 is released
---> Note that if SLE is going to do a summer 2017 SP, then having the kernel released into Leap 3 to 6 months earlier will allow them to get useful wide scale testing in advance.
More brainstorming:
if the kernel team is willing to support 2 kernels simultaneously (as they have done for the last decade plus), then we could have:
Every Fall do a a full Leap release, but based on the roughly 10 month old LTS kernel of the year. Have the fall Leap kernel supported for exactly 12 months after the fall Leap version is released.
Every Spring do a "advanced Kernel" release based on the annual LTS kernel. Support the "advanced kernel" for the last 12 months of that Leap version's support.
During the last 6 months of each Leap version's support, only support the Advance LTS kernel released in the spring after the initial release.
Thus:
Nov 2016 - Release Leap 42.2 with 4.4 kernel
Spring 2017 - Release the Leap 42.2 "advanced kernel" (ie. the 2017 LTS kernel).
Fall 2017 - Release Leap 42.3 with the 2017 LTS kernel (no longer designated advanced).
Fall 2017 - Drop all support for the 4.4 kernel when Leap 42.3 is released
Spring 2018 - Release the 42.3 "advanced kernel" (ie. the 2018 LTS kernel)
Spring 2018 - Drop 2017 LTS kernel support (when Leap 42.2 support is dropped).
The end result is that over the summer 2 kernels are supported: the current LTS kernel and the previous year's LTS kernel.
But during the winter only one kernel is supported.
From the kernel team's perspective they may even be able to leverage SLE kernel support at all times because they will have to support SLE kernels longer than the 12 months I'm proposing. That assumes the SLE will be supporting each of the annual LTS kernels.
Greg
I guess the question to ask is how much do Leap users really care about which exact kernel version they use remembering most of the people that care about having the latest of everything are probably running tumbleweed. Personally as long as my hardware works I have no problem with a older kernel. On the other hand if it comes to April 2017 and theres little overhead in offering what will become the 42.3 kernel in 42.2 alongside the existing kernel we should probably think about offering it. In this case the bigger question is how to make it an optional update and how do we make people aware that they could install this update as we wouldn't want it to be default behavior. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2016-05-25 01:49, Simon Lees wrote:
I guess the question to ask is how much do Leap users really care about which exact kernel version they use remembering most of the people that care about having the latest of everything are probably running tumbleweed. Personally as long as my hardware works I have no problem with a older kernel.
As plain user, I can tell you that we basically want all our hardware to work perfectly. If all our hardware is (relatively) old, the kernel version does not matter much. If one buys a computer now, it does matter a lot. On the on the other hand, don't assume that the user of a stable release is happy with old software. Most of us want the most recent versions available at the time of release of that stable, without the hassle of having to run a distribution that is continuously updating itself with software that is not fully tested (by humans). Just an opinion :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On středa 25. května 2016 3:23 Carlos E. R. wrote:
Most of us want the most recent versions available at the time of release of that stable, without the hassle of having to run a distribution that is continuously updating itself with software that is not fully tested (by humans).
And that is exactly the point: "we, users" want a distribution with latest available versions of all software but without the hassle of having to run software that is not fully tested. Was your mail meant as a joke or did you really manage to miss the conflict between those two requirements? Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-05-25 07:23, Michal Kubecek wrote:
On středa 25. května 2016 3:23 Carlos E. R. wrote:
Most of us want the most recent versions available at the time of release of that stable, without the hassle of having to run a distribution that is continuously updating itself with software that is not fully tested (by humans).
And that is exactly the point: "we, users" want a distribution with latest available versions of all software but without the hassle of having to run software that is not fully tested.
Was your mail meant as a joke or did you really manage to miss the conflict between those two requirements?
Neither. There is a conflict which needs an equilibrium. Notice that the goal was, IMO, fairly well achieved by the SuSE/SUSE/openSUSE distribution for years, till Leap. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 25 May 2016 at 13:58, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-05-25 07:23, Michal Kubecek wrote:
On středa 25. května 2016 3:23 Carlos E. R. wrote:
Most of us want the most recent versions available at the time of release of that stable, without the hassle of having to run a distribution that is continuously updating itself with software that is not fully tested (by humans).
And that is exactly the point: "we, users" want a distribution with latest available versions of all software but without the hassle of having to run software that is not fully tested.
Was your mail meant as a joke or did you really manage to miss the conflict between those two requirements?
Neither. There is a conflict which needs an equilibrium. Notice that the goal was, IMO, fairly well achieved by the SuSE/SUSE/openSUSE distribution for years, till Leap.
Apart from with the very real numbers provided by Michal (thanks!) openSUSE-13.1 (3.11) 665 259 924 openSUSE-13.2 (3.16) 856 187 1043 openSUSE-42.1 (4.1 - LTS) 2473 70 2543 evergreen-11.4 (3.0 / SLE11-SP2) 3778 942 4720 evergreen-13.1 (3.12 / SLE12-SP1) 6208 932 7140 openSUSE-42.2 (4.4 / SLE12-SP2) 1451 257 1708 This quite clearly shows that the openSUSE community suffered with openSUSE 13.1 and 13.2 which compared to 42.2 *already* has more upstream work done to it AND more fixes by our own team. The 'equilibrium' you claim is a false perception that does no measure well with the reality of what really happened in evergreen, openSUSE 13.x, and is happening in Leap. Carlos, you've been around this list long enough, you have probably seen me and Michal argue enough times to think that it would be a cold day in hell before me and him ever agreed about anything Well find a warm jacket, because I agree with Michal. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-05-24 T 19:24 -0400 Greg Freemyer wrote:
From the kernel team's perspective they may even be able to leverage SLE kernel support at all times because they will have to support SLE kernels longer than the 12 months I'm proposing. That assumes the SLE will be supporting each of the annual LTS kernels.
While we do the Kernel version upgrade in SUSE Linux Enterprise 12 SP2 -- and have announced it about 18 months in advance, as our customers and partners expect -- there are currently no plans for a Kernel version upgrade in SUSE Linux Enterprise 12 SP3 (tentative release date: Q4 CY 2017); selective backports may happen, however, we have no details, yet. Hope this helps. So long - MgE -- Matthias G. Eckermann, Director Product Management SUSE Linux Enterprise SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25 May 2016, at 01:24, Greg Freemyer <greg.freemyer@gmail.com> wrote:
Nov 2016 - Release Leap 42.2 with 4.4 kernel
Spring 2017 - Release the Leap 42.2 "advanced kernel" (ie. the 2017 LTS kernel).
Fall 2017 - Release Leap 42.3 with the 2017 LTS kernel (no longer designated advanced).
Fall 2017 - Drop all support for the 4.4 kernel when Leap 42.3 is released
Spring 2018 - Release the 42.3 "advanced kernel" (ie. the 2018 LTS kernel)
Spring 2018 - Drop 2017 LTS kernel support (when Leap 42.2 support is dropped).
The end result is that over the summer 2 kernels are supported: the current LTS kernel and the previous year's LTS kernel.
But during the winter only one kernel is supported.
From the kernel team's perspective they may even be able to leverage SLE kernel support at all times because they will have to support SLE kernels longer than the 12 months I'm proposing. That assumes the SLE will be supporting each of the annual LTS kernels.
Greg, please consider the user impact of what you are proposing. Two kernels in the same distro? Users having to switch to one during the lifecycle of the distro? That complexity and that forced changing brings with it risk - new kernels break things for some people. Some people don't want to take those risks. Those are the people we make Leap for. Leap is never going to support the latest and greatest hardware. It's not meant to. It's meant to be a reliable, dependable, workhorse of a distribution that people can put their faith into. A more moderate pace of change,like the one we currently have, is the best way to accomplish that. For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed. You cannot have it both ways. If you want to leave life on the edge, and your hardware purchases suggest you do, then Tumbleweed is the best platform for you. You cannot crave stability - you're buying hardware so new that no software support is available. 4.6 is just the first version to add support for USB 3.1 Gen 2. There will be bugs. Things will not be stable for USB 3.1 Gen 2 for some kernel versions yet. And before you argue '3.1 Gen 2 is going to take over the world in 12 months, I'd like to point out that USB 3 came out in 2008 and took years before becoming ubiquitous. 3.1 is only just now appearing on new mainstream machines and even then that is Gen 1, fully supported stuff I can find ONE motherboard, a high end MSI gaming board with a Gen 2 card in it So even if they get it right first time and Kernel 4.6 has no USB 3.1 Gen 2 bugs, it's still a whole bunch of change for a very narrow benefit. We're not building Leap to cover every edge case. USB 3.1 Gen 2 is an edge case now, it will be in November, and I do not feel it's support is a compelling argument for playing loose and risk with the entire concept and purpose of what we're doing with Leap. Now, I am not saying that the SLE kernel will make sense for Leap 42.3. Just like we did for 42.1, we are in the position to make the right choice for us. We can talk about that next year, after 42.2's release, when we have very real facts to base our discussions on, such as the state of the upstream kernels at the time and our experience of them within Tumbleweed. But I am certain that choosing 4.4 sets us in a very good foundation for the future. Being an LTS kernel means we can be certain it will be well supported for the full lifespan of 42.2 and, if we choose to not do a kernel upgrade in 42.3, then we know that we still be on a very well supported, stable, LTS kernel. And I guess that's my point, right now, based on the information we have and the points raised to date, I am utterly convinced that the SLE 12 SP2 Kernel (4.4 with whatever backports are already there) is the correct choice for Leap 42.2 I'm open to debate on that point but I feel the arguments need to be stronger than the USB 3.1 Gen 2 case. I'm don't think it's too productive to worry too far into the future such as Leap 42.3 and beyond - that requires speculation or crystal balls, which aren't very useful, or time machines, which we don't even have support for in Tumbleweed yet ;) Sorry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown composed on 2016-05-25 02:08 (UTC+0200):
Two kernels in the same distro? Users having to switch to one during the lifecycle of the distro? That complexity and that forced changing brings with it risk - new kernels break things for some people. Some people don't want to take those risks. Those are the people we make Leap for.
Leap is never going to support the latest and greatest hardware. It's not meant to. It's meant to be a reliable, dependable, workhorse of a distribution that people can put their faith into. .. I'm open to debate on that point but I feel the arguments need to be stronger than the USB 3.1 Gen 2 case.
Those who want the "stability" and "reliability" of Leap are forced to either buy new hardware up to 24 months in advance of need, or ensure when they buy new hardware that its technology is fully 18-24 months old when they buy it. That's got to make some people look for a better distro choice. For comparision, (I realize Fedora supposedly isn't made for people looking for optimium stability), how is it that Fedora can pull off what it does with its kernels? Fedora 21: release kernel 2014-12-09: 3.17.4 last kernel before support termination: 4.1.13 Fedora 22: release kernel 2015-05-26: 4.0.4 current kernel: 4.4.9 Fedora 23: release kernel 2015-11-03: 4.2.3 current kernel: 4.4.9 Fedora 24: release kernel 2016-06-??: 4.5.? Why not instead of the last LTS kernel, release Leap with whatever the last release kernel was at #.2+ in use by TW, e.g. est. 4.7.5 or 4.8.2+ @~8-15 Oct 2016, then have a period 4 months or less following until ~Jan for converting to new LTS with which to stick? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata wrote:
Those who want the "stability" and "reliability" of Leap are forced to either buy new hardware up to 24 months in advance of need, or ensure when they buy new hardware that its technology is fully 18-24 months old when they buy it. That's got to make some people look for a better distro choice.
For comparision, (I realize Fedora supposedly isn't made for people looking for optimium stability), how is it that Fedora can pull off what it does with its kernels?
Fedora 21: release kernel 2014-12-09: 3.17.4 last kernel before support termination: 4.1.13
Fedora 22: release kernel 2015-05-26: 4.0.4 current kernel: 4.4.9
Fedora 23: release kernel 2015-11-03: 4.2.3 current kernel: 4.4.9
Fedora 24: release kernel 2016-06-??: 4.5.?
Why not instead of the last LTS kernel, release Leap with whatever the last release kernel was at #.2+ in use by TW, e.g. est. 4.7.5 or 4.8.2+ @~8-15 Oct 2016, then have a period 4 months or less following until ~Jan for converting to new LTS with which to stick? I fully agree.
Within a Leap release we could also update the kernel and offer Leap downloads with an updated kernel. This would be a real plus for openSUSE. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 25 May 2016 13:28:30 +0200, Bjoern Voigt wrote:
Felix Miata wrote:
Those who want the "stability" and "reliability" of Leap are forced to either buy new hardware up to 24 months in advance of need, or ensure when they buy new hardware that its technology is fully 18-24 months old when they buy it. That's got to make some people look for a better distro choice.
For comparision, (I realize Fedora supposedly isn't made for people looking for optimium stability), how is it that Fedora can pull off what it does with its kernels?
Fedora 21: release kernel 2014-12-09: 3.17.4 last kernel before support termination: 4.1.13
Fedora 22: release kernel 2015-05-26: 4.0.4 current kernel: 4.4.9
Fedora 23: release kernel 2015-11-03: 4.2.3 current kernel: 4.4.9
Fedora 24: release kernel 2016-06-??: 4.5.?
Why not instead of the last LTS kernel, release Leap with whatever the last release kernel was at #.2+ in use by TW, e.g. est. 4.7.5 or 4.8.2+ @~8-15 Oct 2016, then have a period 4 months or less following until ~Jan for converting to new LTS with which to stick? I fully agree.
Within a Leap release we could also update the kernel and offer Leap downloads with an updated kernel. This would be a real plus for openSUSE.
Well, only if people are happy to throw away the kABI compatibility... Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On středa 25. května 2016 2:08 Richard Brown wrote:
But I am certain that choosing 4.4 sets us in a very good foundation for the future. Being an LTS kernel means we can be certain it will be well supported for the full lifespan of 42.2 and, if we choose to not do a kernel upgrade in 42.3, then we know that we still be on a very well supported, stable, LTS kernel.
IMHO the way more important point is it's going to be backed up by SLE maintenance process which is quite a big difference from openSUSE one. Let's take a look at some numbers for recent/current openSUSE kernel branches. Column "stable" shows number of commit id's inherited from (upstream) stable-x.y updates, column "fixes" number of patches in patches.fixes/ (which are supposed to be bugfixes), "sum" is the sum of these two. The metric is far from perfect but it gives some picture: branch based on stable fixes sum ------------------------------------------------------------ openSUSE-13.1 (3.11) 665 259 924 openSUSE-13.2 (3.16) 856 187 1043 openSUSE-42.1 (4.1 - LTS) 2473 70 2543 evergreen-11.4 (3.0 / SLE11-SP2) 3778 942 4720 evergreen-13.1 (3.12 / SLE12-SP1) 6208 932 7140 openSUSE-42.2 (4.4 / SLE12-SP2) 1451 257 1708 First obvious observation is the big difference between the first two (backed by neither upstream LTS nor SLE) and the rest. But it's also apparent that relying only on upstream LTS releases would result in missing a substantial number of bugfixes which were never included in them. After all, these days one can say almost every kernel version has an LTS process of some kind (e.g. out of the 13 versions from 3.12 to 4.4, only 4 do not). SLE maintenance is much more rare. Also, with openSUSE kernel being essentially a SLE one, most openSUSE kernel bugs are going to affect SLE as well which can help get kernel developers' attention to them. After all, we already had three bugs affecting SLE12-SP1 which were first found on Evergreen 13.1. With larger Leap 42.2 user base and 42.2 going to be officially supported, this synergy effect is IMHO going to be much stronger.
And I guess that's my point, right now, based on the information we have and the points raised to date, I am utterly convinced that the SLE 12 SP2 Kernel (4.4 with whatever backports are already there) is the correct choice for Leap 42.2
Agreed. Throwing away the openSUSE-SLE synergy just to get higher version number would be irresponsible, IMHO. After all, there is still the option to run TW kernel on Leap for those who need support for some new hardware but are not adventurous enough to go full Tumbleweed. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 25 May 2016 00:38, Richard Brown <RBrownCCB@...> wrote:
In another thread, Yamaban brainstormed the following kind of schedule for future Leap/SLE releases
On 25 May 2016 at 00:20, Yamaban <foerster@lisas.de> wrote:
In light of the LTS kernel the only thing would be to move the release date of Leap / SLE, e.g.
- Kernel in January / settling in Tumbleweed
- Leap first Alpha in late February / early March
- Leap first Beta mid/late April
- SLE (sp) first Alpha early May
- Leap freeze late May
- SLE (sp) first Beta mid June
- Leap last full patch pull-in / first RC mid/late June
- SLE (sp) freeze early July / or better mid August
- Leap release mid/late July
- SLE (sp) last full patch pull-in / first RC early / mid September
- SLE (sp) release early / mid October
I want to compare that to where we are right now with SLE 12 SP2 and Leap 42.2
- Kernel in January / settling in Tumbleweed
- SLE 12 SP2 Alphas in Q1 2016
- SLE 12 SP2 Beta started late May <- NOTE: Leap 42.2 Development cannot start in earnest until SLE sources are available, and SLE sources cannot be available until Beta
- Leap 42.2 first Alpha TODAY <- THIS IS WHERE WE ARE :)
- Leap Alphas & SLE Betas over the next few months (aka 'Q2')
- Leap Betas & SLE RC's after that (aka 'Q3')
- SLE 12 SP2 Release in 'Q4'
- Leap RC's in late Sept/October
- Leap 42.2 Release in November
Benefits of this current approach over what Yamaban proposed (Leap & SLE interleaved)
- Leap release is still in November, which in 10 years of openSUSE releases we've proven that releases at that time for year works for us
- Winter/Spring releases get too disrupted by Christmas, Summer releases get disrupted by summer holidays. October/November is the time that works for us best.
- There is a nice symmetry of what we are doing with Leap and what SUSE are doing with SLE. Our major milestones are aligned. Developers working on SLE are directly benefiting Leap and visa versa
- This timeline has the possibility for stuff like SUSE QA engineers actually working on Leap when SLE development is wrapping up but Leap will be at the prime interesting time of RC's and GMC.
- We'll avoid the situation we had with 42.1 (where Leap released a few weeks before SLE 12 SP1) and then we had a pretty huge 'mega update' to sync up Leap 42.1 with the SLE 12 SP1 shared packages
- It accepts the reality that Leap is a fair bit bigger (in terms of package numbers) than SLE - I think Yamabans suggested timeline is a little too aggressive. Even if we could realistically start Leap development before our base system had even started to come together, trying to properly integrate our 8000+ source packages in that kind of timescale is pretty much impossible.
Downsides of the Yamaban proposed approach (the "Leap before SLE" schedule)
- Um..actually I'm no sure there is any benefit..a July release is pretty much impossible when most of the community goes on vacation over summer..releasing that much earlier than SLE means we'll have to miss out on a whole bunch of stuff or have a rough few months keeping everything in sync as SLE comes together..yeah..um..sorry I WANTED to try and write a balanced approach but I think our current roadmap is the absolute best plan we can have given our desire to release something annually and with what SUSE are planning for SLE 12 SP2
@Richard: There was no critic to the approach / schedule we use now intended. This is but a try to feel out, if there is a possiblity to get Leap out earlier in the year / nearer to the LTS kernel release. Playing it through, I got very soon to the point that a April release for Leap and a October release for SLE (Hello Ubuntu), will simply not work for us here at (open)SUSE. Trying other variants, comparing these to past experiances, the propsal above was the only one where I got to a Leap before main summer vacation and still a hefty benefit for the SLE team. It was the best of ca. 30 or so tries. And only possible because of Tumbleweed doing the heavy-lifting beforehand (Kernel-, compiler-, tool-chain- upgrade, full rebuild). Still, for up comming release a full support for the Intel Skylake cpus, esp. the IRIS 550 / 580 gpus should a fix-point. That will need some, for the 4.4.0 missed out / forgotten patches for the kernel, and Mesa 11.3 (will come June) at minium. If we can lobby for some more drm / amd / nouveau / late fixes backport, we all will benefit, but IMHO this has to happen upstream. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (12)
-
Andreas Schwab -
Bjoern Voigt -
Carlos E. R. -
Felix Miata -
Greg Freemyer -
Matthias G. Eckermann -
Michal Kubecek -
Richard Brown -
Richard Brown -
Simon Lees -
Takashi Iwai -
Yamaban