[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
> 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
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