John Plocher wrote:
Darren J Moffat wrote:
John Plocher wrote:
James Carlson wrote:
The issue with release management still seems murky to me. I assume
that distributions do not get to manage uname -r, unless they're
willing to fork. If this is the ON community's task, then how
(reasonably) do distributions identify their releases?
Solaris uses /etc/release to tag their product.
uname is simply the version information for one of the components
used to
construct Solaris. java --version is another, as is
gnome:About:popup...
uname -r is the tag that determines if the given release of Solaris is
Major, Minor, Micro.
No, it only determines whether or not the release of the ON *Consolidation*
that went into Solaris is Major, Minor or Micro. It has nothing to do with
the taxonomy of the vinyl binder of CDs that ships in the box labeled
"Solaris10" outside of the unfortunate fact that Marketing chooses to
brand their product with words that are related to their perception of
uname's output.
Nevertheless, they *are* two different things. Even if they sound the
same.
Uname says SunOS 5.10. Marketing says Solaris10. Enginerds see a
connection
and jump to unwarrented conclusions :-)
As an aside,
most people seem to have reached that same conclusion, needlessly deviating
from it doesn't seem wise.
In my world view, the OpenSolaris ON Core Community owns uname,
They own the source to uname yes. But do they get to set the policy
of what value uname -r returns
Absolutely yes.
and how does that interact with what a given distro wants as their
type of distro?
A distro may choose to use the work product of the OpenSolaris community,
or (as you say) it may choose to fork. Changing uname is a fork. At that
point, the code used by that distro is no longer compatible with the code
released by the OS/ON community due to the choices made by that distro's
developers.
If I want I can create a distro that has this uname output:
MyOS localhost 0.99.99p1 flibertyflop sun4u sparc SUNW,Sun-Fire
Certainly. And, if you do, you can no longer claim to be compatible with
the code released by the OS/ON community. Derived from, certainly, but no
longer compatible.
-John
The more I think about it, the more messy having this kind of autonomy at
the consolidation level seems to become.
Historically, as best as I know, it hasn't existed (though in the case of
JDS, it maybe somewhat present), I can't currently see any reason that it
must exist, or, frankly, any benefit (other than perhaps forcing cleaner
architecture) stemming from it.
To take the hypothetical Major release further. JDS decides on a micro
release, SFW, X and Install decide on a minor release, on ON decides on a
major release. All niceties aside, what you're left with is unlikely to be
a product, but a mess.
In theory, certainly, you could pick appropriate prior releases of
consolidations of a release of greater magnitude than your desires, probably
cherry picking changes from after that release to meet feature and bug-count
goals, but I doubt it would be pleasant, and of course, you'd have to
continue this until the planets aligned with your release goals.
I guess I feel that the consolidated nature should remain, different
consolidations, all OpenSolaris, and that such things should be done as a
whole (perhaps by an appropriate group from each consolidation or whatever).
Though little of this has any direct bearing on sch's initial request, but I
guess that's my fault. :-)
-- Rich
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
