Darren Reed wrote:
...
I've already said this in an off-list reply, but I guess I'll say it again here.
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.
...
Well, until we in Sun engineering are doing direct putbacks into OpenSolaris,
there will need to be an onxx-gate, period, that OpenSolaris is synchronised with.
Eventually there should be an onxx-gate that is being updated from OpenSolaris and
we test that. Until we (Sun) eliminate usr/closed, we cannot use OpenSolaris as
"the gate" to test or build a direct release from.
Not for ON, no. And it's not a matter of eliminating usr/closed at all, the
stated plan is for usr/closed to be a separate workspace (onXX-closed).
Furthermore, each distro that uses OpenSolaris will also be slightly different.
From a technical point of view, the reality of the situation is that then main
OpenSolaris gate (in its pure form) is never tested by us or any build as it exists
if you checkout that source code, alone. Only when usr/closed is eliminated can it
be any different.
Again, no. The *exact* same usr/src is used by both you and us, usr/closed
is *entirely* irrelevant to this part of the discussion. (not least because
it's largely an ON specific issue, right now).
Now to be more loose here and ignore the usr/closed problem, the current source
code tree that we use for development in Sun, I expect, will be the same as
OpenSolaris's current source code tree. In this case, the primary gate (OpenSolaris)
gets tested in the same fashion that nevada does today - it doesn't suffer from
"no testing."
Not *NOW*, no, but we aren't talking about now. Part of this discussion was
about each distribution (including Sun) releasing from branches, If Solaris
builds were to come from a sun-specific branch, that could include SX:CR
coming from said branch. Given that (last I knew) there was not enough open
code to form an installed system capable of building itself, that would lead
to the "other" gate getting no testing.
So...
If OSbY (OpenSolaris build Y) is based on onnvX (Nevada build X), my suggestion would be
that at some point in time we decide that a value of X is going to be the new MR and becomes
(say) on11. Some sort of announcement is made regarding OSbY, source code in OS is tagged,
etc. onnv continues with people doing putbacks into it and the ongoing sync between onnv and
OS. on11 would be created something like "cp -rp onnv-gate on11-gate" (mmm, gotta love
teamware.)
Which is precisely how things work now (with the exception that onnv should
not be the next MR gate name in that situation, and that if all goes well,
you won't be using TeamWare for it).
For all intents and purposes, the testing the internal opensolaris-based
tree (currently onnv) should be the equivalent of testing OpenSolaris.
If the 'main' gate, and the gate Sun build, test, and release from stay the
same that would be true, which is my *entire point*.
-- Rich
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
