I'm really glad you are doing this, and this is actually the reason why I joined the list. Originally I proposed the idea of doing "CentOS Green" to the centos guys a bit back but they tabled the idea. Dag Wieers (rpmforge guy) was the guy who was interested but he didn't have the right introductions to the SUSE community as he was a Red Hat-oriented guy. Now that Dag is no longer involved in CentOS I think would be a good time to bring him in, because this will need dedicated resources to work on it or at least a bunch of volunteers with a vested interest in the project.

From a wishful thinking perspective I would like to see a full-blown openSLES based on SLE source. But I agree, this might antagonize Novell if it was under the auspices of openSUSE and would have to be spun off as a separate entity from openSUSE if that direction were to be pursued -- which is why I was originally thinking the CentOS guys. We could form a new home for it, but there is a lot of startup infrastructure that would be needed.

I think the desired approach would be to continue alignment with openSUSE as a openSUSE/Novell sponsored "flavor" of openSUSE, using openSUSE packages, however matching functionality on a package-by-package basis with SLE, although not necessarily the same package versions, we would use the openSUSE packages. I think an "LTS openSUSE Server" makes sense, something with a 24 or 36 month support lifecycle. I also think that "openSUSE Server Edition" has a lot of potential if we use SUSE Studio as the basis for compiling the distro, with some sort of permanent download area. This would serve as a good "demo" of SUSE Studio for Novell's marketing purposes and ensure their support for the project. On Mon, Aug 24, 2009 at 3:23 PM, Boyd Lynn Gerber<gerberb@zenez.com> wrote:

Hello,

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.

I am reporting back the significant points from the new ML created.  To sum things up...

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)

6.  The guidelines should be written down and rpmlint checks made where     possible to insure we abide by the guidelines and avoid legal issues.

There are basically two choices as the subject reports.

1.  openSUSE LTS        A longer life spam 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 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 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").

Therefore I fee the right option is the do an openSLES, but this as of yet has not been decided.

* bsgit http://gitorious.org/opensuse/bsgit

-- Boyd Gerber <gerberb@zenez.com> 801 849-0213 ZENEZ   1042 East Fort Union #135, Midvale Utah  84047 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-- Jason Perlow jperlow@gmail.com (201)735-5838 Twitter: http://twitter.com/jperlow Technology Columnist, ZDNet Tech Broiler (http://blogs.zdnet.com/perlow) Blogger/Podcaster, Off The Broiler (http://www.offthebroiler.com) LinkedIn Public Profile: http://www.linkedin.com/in/jasonperlow -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

I'm really glad you are doing this, and this is actually the reason why I joined the list. Originally I proposed the idea of doing "CentOS Green" to the centos guys a bit back but they tabled the idea. Dag Wieers (rpmforge guy) was the guy who was interested but he didn't have the right introductions to the SUSE community as he was a Red Hat-oriented guy. Now that Dag is no longer involved in CentOS I think would be a good time to bring him in, because this will need dedicated resources to work on it or at least a bunch of volunteers with a vested interest in the project.

From a wishful thinking perspective I would like to see a full-blown openSLES based on SLE source. But I agree, this might antagonize Novell if it was under the auspices of openSUSE and would have to be spun off as a separate entity from openSUSE if that direction were to be pursued -- which is why I was originally thinking the CentOS guys. We could form a new home for it, but there is a lot of startup infrastructure that would be needed.

I think the desired approach would be to continue alignment with openSUSE as a openSUSE/Novell sponsored "flavor" of openSUSE, using openSUSE packages, however matching functionality on a package-by-package basis with SLE, although not necessarily the same package versions, we would use the openSUSE packages. I think an "LTS openSUSE Server" makes sense, something with a 24 or 36 month support lifecycle. I also think that "openSUSE Server Edition" has a lot of potential if we use SUSE Studio as the basis for compiling the distro, with some sort of permanent download area. This would serve as a good "demo" of SUSE Studio for Novell's marketing purposes and ensure their support for the project. On Mon, Aug 24, 2009 at 3:23 PM, Boyd Lynn Gerber<gerberb@zenez.com> wrote:

Hello,

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.

I am reporting back the significant points from the new ML created.  To sum things up...

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)

6.  The guidelines should be written down and rpmlint checks made where     possible to insure we abide by the guidelines and avoid legal issues.

There are basically two choices as the subject reports.

1.  openSUSE LTS        A longer life spam 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 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 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").

Therefore I fee the right option is the do an openSLES, but this as of yet has not been decided.

* bsgit http://gitorious.org/opensuse/bsgit

-- Boyd Gerber <gerberb@zenez.com> 801 849-0213 ZENEZ   1042 East Fort Union #135, Midvale Utah  84047 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-- Jason Perlow jperlow@gmail.com (201)735-5838 Twitter: http://twitter.com/jperlow Technology Columnist, ZDNet Tech Broiler (http://blogs.zdnet.com/perlow) Blogger/Podcaster, Off The Broiler (http://www.offthebroiler.com) LinkedIn Public Profile: http://www.linkedin.com/in/jasonperlow -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org