> OSEE - OpenSolaris Enterprise Edition (classic Solaris)
> OSCE - OpenSolaris Community Edition (swiss army knife distro)
Please don't take my comments as throwing cold water on your
strawman; rather, try to use them to help drive a deeper common
understanding. I agree with you - we really need to have this
kind of discussion.
Sorry, I missed replying to this thread.
> I would say you have one main branch (let's call in OSM: OpenSolaris
> Main). the OSEE and OSCE distros would take what is in that main
> branch and make modifications to that base. (Preferably just adding to
> it.)
In poor "word pictures", I think we have this today with
either (a true source code management system view)
OSM = Solaris10RR baseline as of June 2005
|
+- OSEE = Solaris10 update releases
+- OSCE = OpenSolaris-Nevada (Minor Release)
This would be the simplest to implement, and the most likely course of action.
or (a cherry picking model requiring manual back porting
of desired features from Nevada)
OSM = Solaris10RR baseline as of June 2005
|
+- OSCE = OpenSolaris-Nevada (Minor Release)
|
+- OSEE = Solaris10 update releases (pseudo-child of Nevada)
+- Solaris Express
+- The various existing OS.o distros
Ok let me explain what I want:
S100RR = Solaris10RR baseline as of June 2005 (Is now SXCE)
|
+ OSM = A completely Opensource Nevada distro/sourcebase. (Our
starting point.)
|
+- OSCE = OpenSolaris-Nevada - Linuxy/Indiana distro (this is a
delta against OSM)
+- OSEE = Communituy update releases (maybe Belenix based) (This would be an
| | OpenSolaris supported distribution of what is
now being called SXCE)
| +- Solaris Express (Sun's version of OSEE that will be feed
into the product Solaris)
+- The various existing OS.o distros
Changes are reviewed by the ARC for inclusion into OSM, just as they
are currently done for Nevada. If for some reason they do not fit, and
cause a conflict between OSCE and OSEE, they would be moved into the
delta summary of that distro.
Please let me know if I am unclear.
One could evolve either of these into a more radical
scenario where we charter a new Major release:
OSM = Solaris10RR baseline as of June 2005
|
+- OSEE = OpenSolaris-Nevada (Minor Release of ON5.10)
| |
| +- Solaris10 update releases (pseudo-child of Nevada)
| +- Belinix
| +- Schillix
| +- Martux
|
+- OSCE = OpenSolaris-1.0 (Major Release)
|
+- Solaris 3.0 (aka SunOS 6.0...)
+- Nexenta
(Don't ask where Indiana fits here - I haven't a clue.
As it is, I'm probably maligning Moinak, Erast, Joerg and
Martin :-)
This is interesting, but I'm sure no-one really wants a completely
separate code fork for the Community Edition...
> When any addition is to be made to a OSEE or OSCE, it must be
> evaluated for integration into OSM. (With input from the community)
In the ARC world view, part of this evaluation is to see
if the "scope of change proposed" matches the target's
"scope of change allowed", based on the expectations set
by the project that first introduced the things being
changed, the interface and release taxonomies, and which
(if any) things are going to be changed incompatibly.
Think of this as:
You promised us that XXX would exhibit <some level
of stability>, and now you wish to break it. The
"magic decoder ring" says you can do so only in a
<it picks one: Major, Minor, Micro> release tree.
This means that, depending on their release taxonomy
bindings, changes that are allowed in OSCE might not
be allowed in OSM or OSEE. (duh! :-)
> I would expect ISVs to port their apps to OSes that Sun distributes
> and supports.
Today Sun distributes and supports
Solaris 8
Solaris 9
Solaris 10
Solaris 10 update 1,2,3,4...
Solaris Express
Solaris Developer Express
Historically, ISVs (and Blastwave, too :-) tended to support
only Solaris 8, counting on binary compatibility to let it
"just run" on S9 and S10. I'd guess that the number
supporting S10 is still ramping up. I wouldn't expect
anyone to be offering SX or SDX support at this time,
though I assume that many are playing with it "in house".
Can I get commercial support for SX/SDX from Sun? I know it is
distributed by Sun, but I thought it was strictly buyer beware?
The $64K question is whether any of them would support a
non-Sun distro; just as interesting is whether or not any
of the various distro-producers would care and/or whether
there was any expectation of compatibility between distros.
I don't think this really matters, as this is entirely up to the third
party developers. (I suspect their decisions would largely be driven
by customer demand).
One other note, my feeling is that the community edition would be
initially geared more towards those that want a platform for running
open source applications, vs. heavyweight commercial applications.
> You wouldn't need an entire team, as a lot of the work would be in
> OSM. The thought would be that Sun developers would focus on OSM, and
> OSEE, with a few bodies dedicated to OSCE. Most of the community work
> would be done in OSM and OSCE, with the goal to backport any
> universally useful OSCE changes into OSM, so that OSEE can leverage
> that work.
When I read your comments above, I get the impression that
there will be two rather disjoint communities - the Sun-
dominated OSM/OSEE one and the non-Sun dominated OSCE.
If this is how it works out, what would motivate the OSCE
crowd to do the backport work, especially since it would
undoubtedly involve more work?
There would be one main community: OSM. If something is ruled out of
scope by ARC, it will have to be picked up for inclusion into OSCE.
(Or someother distro) If something that is initially ruled our of
scope ends up becoming widely deployed, it would be up to OSM/OSCE to
coordinate with OSCE, to move it back into the mainline if so desired.
brian
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
