Beginning History of Project
Beginning History of Project
Many of us have been thinking about this for years...
openFATE #306982: Create an open SLES
https://features.opensuse.org/306982
really started the ball rolling on this idea and gave it life.
We need a set of guidelines that must be followed. These should include...
URL's for the Guidelines we should/must reference are as follows..
openSUSE http://en.opensuse.org/Packaging
Fedora https://fedoraproject.org/wiki/Packaging/Guidelines
We need to define a set of guidelines for either project we choose. These guidelines with be used and need to be reveiwed by someone with legal knowledge. Once we define these guidelines we will post them as an RFC to the opensuse-project ML.
So to sum things up.
1. I see us creating a server OS with long lifetime.
2. Packages have to be 100 % binary compatible with our defined target. We need a set of guidelines that must be followed. These should include...URL's for the Guidelines we should/must reference are as follows..
openSUSE http://en.opensuse.org/Packaging
Fedora https://fedoraproject.org/wiki/Packaging/Guidelines
We need to define a set of guidelines for either project we choose. These guidelines with be used and need to be reveiwed by someone with legal knowledge. Once we define these guidelines we will post them as an RFC to the opensuse-project ML.
So to sum things up.
1. I see us creating a server OS with long lifetime.
2. Packages have to be 100 % binary compatible with our defined target. Only aberrations with removal of trademarks and or legal reasons are allowed.
3. Every change has to be reproducable and tracked via an available SCM.
I personally prefer GIT. We need to make sure we keep in mind using an OBS as the prefered method of doing the task of building and releasing, and other things it provides. This can be local BS or on the OBS. The GIT GSOC project bsgit(*) provided a great front end to the OBS. may assist us in this task. The code finish code has to be made publically available.
4. Every code change to the project has to have a SR and the 3 positive votes accepting it before it is published. (Model after openSUSE Factory).
5. We need legal advice on the setup of the packaging guidelines. (What we have to remove to stay legal, and (Not much in the way of legal would be needed for openSUSE LTS)
There are basically two choices as the subject reports.
1. openSUSE LTS A longer life span of openSUSE releases.
2. openSLE(S,D) A binary compatible with SLES/SLED
> From all the information gathered from the various contacts openSLED is really not an option. openSUSE and SLED fill this requirement. So there is not a need for it.
So the group must decide on which of the openSUSE LTS or openSLES they want to do. This is what I have so far on pros and cons for each.
openSLE
Pro
1. security fixes are already done for the lifetime of the release.
2. Smaller number of rpm's
3. Server oriented without a lot of clutter.
4. All that would be needed is to remove the branding and rebrand it for openSLE. A much smaller task.
5. Binary compatible for SLES.
Cons
1. Possiblity of antagonizing the Novell upper management.(Probable)
2. Not the most politically acceptable solution
3. Needs legal advice to conform to legal requirements.
4. Needs a legal entity to control the SLES subscription and have the ability to get the patches to SLES. (Might be considered a pro)
5. May need community provided local BS.
openSUSE LTS
Pros
1. No real legal issues.
2. The ability to choose just the OSS easily.
3. Large base of openSUSE users.
4. Definitely able to use the OBS.
5. Community driven in all ways.
Cons
1. More packages that have to be paired down to a workable number.
2. Community driven in all ways.
3. Do we have enough people we trust to do back ports over the lifetime?
4. Need highly driven members as everything will be on their sholders.
5. I feel there will be more work with openSUSE LTS than with openSLE.
It had said time and time again that the openSUSE community is free to create a community supported LTS and Novell will assist and provide the necessary infrastructure(BS) and other in house projects to make BS GIT backend and front end compatiable, but will not help by maintaining any packages.
Personally I really doubt there are enough willing and able people in the current community to properly backport e.g. security fixes, drivers for the kernel, and so on. This is why I think the idea of a "cummunity supported LTS" won't work. (or at least will not produce anything "One would want to run on a publice server"). But this is changing in that it has been expressed that the openSUSE TEAM from Novell would consider training or assist those non-Novell Community Members to do this function. With the things expressed at the big conference in September that the balance may have changed in favor of an openSUSE LTS
Before the September conference and talks with various people, the timing for an openSLES really is not right. Novell has just announced it is finally in the Black the end of Feburary/First of March 2010. Therefore I feel that right option is the do an openSUSE LTS as we will have the support of Novell which is nessary for this project to succedd, but this has as of this time not been decided.
For example is a start toward our goals.
One of the main reason this project is moving at such a slow pace at the moment is I(Boyd Gerber) have had something similar to a stroke happen and it has made it near impossible for me to work on it at the moment. And no-one else has stepped up to lead the project so it is going at the pace that I am currently able to push this project.
Possibly ask openSUSE Art Team to come up with some logos to replace the one currently at the top of the page.
Novell® is a registered Trademark.
SUSE® is a registered Trademark.
openSUSE® is a registered Trademark.
