[openSLE] OpenSUSE LTS or openSLES.

Boyd Lynn Gerber gerberb at zenez.com
Mon Aug 31 13:29:01 MDT 2009


On Mon, 31 Aug 2009, Nathan Willis wrote:
> O.K.; I've read through the list, and there are one or two things I'd 
> like to understand better.
>
> First, I take it from context that you do consulting -- could you 
> explain in a little bit more detail what sort of consulting (or other 
> business) it is? That seems to impact the discussion because of the 
> types of customers (ie SMBs) that you run into, and how the exist SUSE 
> options fit/don't fit them. So I'd like to make sure I'm clear on what 
> the scenario is, just so I don't misunderstand.

I do consulting to many various businesses.  I believe the application 
determines the best OS for the job.  Many of us that once were Novell Vars 
for their Netware stuff have come together as well.  I have tried to show 
this from all the various different people I have talked with.  The best 
discussions have been on IRC.  What we have gleamed is that business do 
not want to worry about what OS they are running their business's on, but 
want to treat it as a tool to be used to further their business's.  They 
want to do what they do best and that is run their business.  They use the 
tools available to make their business's the best.  One aspect of running 
their business is having a web presence.  What they use has to be as a 
tool that they do not have to invest much time.  One way to provide this 
is having a rock solid OS that does not have to change very often.  The OS 
has to be patched to provide the necessary security to prevent problems to 
their tool.

> Second, I think I get the ins-and-outs of how a OpenSLES distro might
> function, but the less-likely OpenSUSE LTS; would that have just meant a
> large team of people volunteering to back-port fixes to old OpenSUSE
> releases?  I can certainly see how that would not be feasible, but again I
> want to make sure I have my facts right.

An openSUSE LTS would have to have people that are trusted to port 
security fixes back to the OS version.  It in my opinion would require a 
much larger team as Novell stops doing security fixes after 18 months. 
The big issue of trust really comes into play here.  Who do you trust to 
bring security fixes back.  How skilled are they?  Also for an openSUSE 
LTS the number of packages would have to be prunned.  The discussion has 
been to use the same packages that are in SLES but from the openSUSE 
version.  Personally I do not see it as being very realistic doing an 
openSUSE LTS with the current community.  I feel the resources are not 
there do handle the scope of an openSUSE LTS.  That is why my preference 
is openSLES.  Novell provides the security fixes for th 7 year lifetime of 
each SLES version.  So by doing a openSLES we would be able to use that 
and remove the branding much the way it is done for CentOS right now.

> Third, if the interested parties decide en masse to pursue an OpenSLES, 
> what would be the next step?  How do you move forward, organizing the 
> volunteers for example?

I see the steps as follows.

 	1.  Create a set of guidelines for the project.
 	2.  Have them reviewed by a compatent lawyer to make sure
 	    we do not violate any Novell copyrights or patents in the US.
 	3.  Create where possible rpmlint rules to make sure we are
 	    compliant with the guidelines established.
 	4.  Create a legal entity that has a valid SLES. (may not be
 	    needed)
 	5.  The members of the entity or group would then meet and decide
 	    "What VCS should be used?"  Depending on the VCS create a
 	    public repo for the source.
 	6.  Either use the OBS or create a local BS for the project.
 	7.  All changes would need to be aproved by at least 3 people
 	    before they are made public/published.

Personally, I see using git and having these repositories or branches.

 	Master (final place where all approved changes kept and are ready 
for deployment when a release is to be done.
 		a) This is the main development branch.
 		b) Everything must be graduated from next.
 		c) This would follow the SLES development

 	Next	A stagging area where the patches are tested and vetted 
for bugs and approval.  They remain here till 3 people have approved them 
and if necessary under go a legal review.

 	Stagging  A public repo/branch where we track all proposed
 		changes.  This is where the SLES packages would be brought
 		into the project and under go the removal of everything
 		that is needed.  Once done they would be moved to next
 		where they under go the approval process.

 	Maintainence.  Will track the SLES service packs and go through
 	the above.  This branch will be exactly the same as the SLES
 	service packes.  It will be branched from master to mirror SLES.

So all in all an openSLES in my opinion is the best option for the group 
we currently have.  We are right now trying to iron out the guidelines. 
The guidelines appy equally to either option openSUSE LTS or openSLES.

I really do not see an openSLED.  Curentl SLED and openSUSE really fit 
this niche really well.

If you have any other questions please ask.

-- 
Boyd Gerber <gerberb at zenez.com> 801 849-0213
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047


More information about the OpenSLE mailing list