Having everyone release their distribution from branches leaves us with the
gate entirely divorced from a binary deliverable. In that situation it would
get little to no testing. This is bad bad bad.
That's an excellent concern and I certainly wasn't advocating nobody
using or testing the output from the trunk itself. :-) Please check
the "Quality Criteria" section from the same section of the draft.
Perhaps there should be some sort of binary output produced by the
OpenSolaris project which combines the consolidations together. But
that isn't Solaris Express Community Edition, either today or what it
might be in the future since SXCR represents a snapshot of what Sun
plans to ship in the future. SXCR might not for some reason even
include all of the consolidations represented in OpenSolaris or it may
have some other changes that have been rejected by the community.
Now, if this were to be done (to use 'now' as an example) like this.
- Nevada stabilizes (becomes Sun's release branch).
- Nevada+1 appears (becomes the next MR gate)
- Installable builds from both continue to appear on the same bi-weekly
schedule
- belenix, nexenta, and whoever else are free (as they are now, and always
have been...) to create $THEM-r$WHATEVER branches for their release
engineering.
That would perhaps work, I think. (it would also be pretty much identical to
as things are already...)
Yes, that is pretty much identical to what we have today. But the
installable builds are snapshots of the next release of Sun's
distribution and include changes that are not part of OpenSolaris.
On the other hand:
- onxx-gate --- "main" branch, yet nobody actually installs from it.
- sunonxx-gate --- Sun's branch, with builds (and SX/SXCR) coming from it.
- belonxx-gate --- Belenix branch, with their builds coming from that.
- .....
Would lead to merge hell, onxx-gate getting little actual testing, and would
be utterly catastrophic, in my view.
But in many ways that is what happens today. The "sunonxx-gate"
represents the gate where Sun's own supported distribution comes from.
At the moment, that's the Solaris 10 patch gate but in the future, it
might be the sustaining release of the release that comes after Solaris
10 (I'm not going to give it a name!).
If there was an OpenSolaris binary product akin to the output of Fedora
Core, that would be where I expect a great deal of testing to be taking
place on the trunk. Changes to that would then trickle down to other
distributions including presumedly Solaris itself.
dsc
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
