Categories
Technology

Using SLE for openSUSE

There is a very interesting set of conversations happening within the openSUSE Project and openSUSE Factory mailing lists. The focus is on what, if anything, to do with the newly released SUSE Linux Enterprise sources on the Open Build Service.

I’d recommend that you head over to the mailing lists in order to read up on the entire discussion if you have any interest at all. I’m going to use this time to give my thoughts on where the openSUSE project might want to do for the future.

I’ll preface this by stating there are only my opinions and really serve to make my work easier. Whether the openSUSE community feels this way is a question I cannot answer.

I tend to think it is foolhardy to try to please everyone even some of the time. What makes a good project and/or product is making hard decisions about direction and focus.

Tumbleweed

Tumbleweed should stay Tumbleweed and keep doing what they are doing. There is no use trying to slow it down, you just need to keep pushing ahead. Get some additional resources behinds it, start to try to find some ways around the problems binary drivers can cause, and keep plugging again.

Overall, I’ve found Tumbleweed to be really fun and stable enough to use on a day-to-day basis, even for work. It is not going to please everyone (as the kerfuffle over making KDE 5 the default is causing for some at the moment), so don’t even try.

It is a rolling distribution for developers and contributors using some amazing tooling (like openQA and Open Build Service (OBS) to name a couple). Let it continue to be just that.

openSUSE Next

Here is the fun part. I am using the name “openSUSE Next” for this blog post. I might change it to openSUSE X in the future … just because it really doesn’t have a name.

  • Base the release off of the recently-released SUSE Enterprise Linux sources. I’m not sure what is all in there, but build on the work SUSE is already doing and providing.
  • Take full advantage of openQA and OBS to supply a MUCH LARGER selection of packages than SUSE can (or wants to) for SLE.
  • Refocus efforts on “filling in the gaps” from SLE. Release newer desktop environments sooner than SUSE can or should. Update user-facing packages before SUSE can or should. Focus on the things that will set openSUSE apart from SUSE Enterprise Linux.
  • Make openSUSE Next a great platform to build on top of.

The last bullet is the one that hits closest for me. Make openSUSE the premier Linux distribution for building “things” on top of. I think part of this is accomplished through having consistent support.

  • Schedule releases around SLE releases. For example, openSUSE Next 1.1 could ship close to when SLE 12 SP1 ships. Then when SLE 12 SP2 is getting ready, openSUSE Next 1.2 is next up.
  • Normal support for each release is 18 months (or the next release plus six months).
  • “Evergreen” support (it doesn’t have to be, but I’ll stick with the name) happens at the end of each main release. For example, if SLE 12 SP3 is the last service pack before SLE 13, then openSUSE Next 1.3 would receive “Evergreen” support of another 18 months (grand total of 3 years of support for openSUSE Next 1.3).
  • The process starts over again with SLE 13 coinciding with openSUSE Next 2 being released. When openSUSE Next 2.1 is release, openSUSE Next 2 has six months of support left. Then it keeps going.

In the oddball case of openSUSE Next 1, that release line would receive up to 3.5 years of support or 4.5 years if you include “Evergreen” in that number. It doesn’t mean a single release does, but if you follow the interim releases, you can stick with openSUSE Next 1 for up to 4.5 years.

For openSUSE 2, it would be even better (since you get the SLE 13, SLE 13 SP1, SLE 13 SP2, and SLE 13 SP3 releases to work with): 4.5 years of updates and 5.5 years if you go with “Evergreen” support at the end.

Here’s a clearer look at what I am thinking:

openSUSE Next Timeline

Because you are building on top of the work of SUSE, you get that stable base to build on top of that will get patches, and security updates, and fixes for ever longer.

This is a unique opportunity to not just rehash what is already there (like CentOS, a great option), but to build something a little bit different, a little bit broader, a little more ambitious.

I’m going to continue to watch and chime in when I feel it is needed, but this is just a single idea on where the community could go.

Comments are closed.