Richard Lowe wrote:
> Stephen Hahn wrote:
>> I recently wrote a bit about the restricted integration builds we had
>> during December at
>>
>>
>> http://blogs.sun.com/sch/entry/opensolaris_restricted_builds_through_the
>>
>> One of the aspects I believe we need to settle on is an initial
>> frequency for such restrictions. I've talked with at least one of
>> the non-Sun distributions on this topic, and with some of the Solaris
>> Nevada people as well, but a bit more discussion is needed. (I can
>> write a further essay on the merits/problems with restricted builds,
>> if that would help.) Looking at past releases, distribution releases
>> (across the various OpenSolaris derived distributions), and
>> hypothesizing about the needs of organizations choosing to build atop
>> the OpenSolaris code, my initial suggestion is that we have a one or
>> two build restricted integration period every three months. That
>> means, roughly 5 - 6 open builds followed by 1 - 2 restricted ones.
>>
>> Thoughts?
>>
>
> I think that could work, however, how would things look up on the
> lead-in to a Solaris release? (the 6-ish months of various
> restrictions leading up to 10, and the 2.5-ish leading up to 9).
>
> I'm aware that on+2 tends to appear somewhat before on+1 is finished
> (at least, I recall the old comments opengrok used to show, showing
> merges from on10 into onnv, for a what seemed like a fairly reasonable
> period).
>
> I think this needs to be thought about with an eye to the various
> constraints. Off the top of my head:
>
> - Sun need a longer period of stabilization prior to a release.
> - At least some people outside of Sun will probably not want that to
> hold up
> their development in general.
> - the various source trees need to precisely match their equivalent
> 'used to
> build Solaris' trees at all times, at least for the foreseeable future.
>
> does on+2 appear far enough before on+1 is done that none of these
> will be problematic? could it? (though I accept it would probably be
> rather quiet until on+1 was done).
>
> In other words, to take the 6 month-ish period of restrictions at the
> end of on10, when in that period did onnv appear? When could we
> expect it to appear for nevada++?
>
> Do people care enough about the light restriction for a 10-like cycle
> to actually be a problem in that way at all?
>
> The above is all assuming that onnv and onnv+1 will be visible to us
> concurrently (and similar for onnv-patch/on11-patch, probably).
Actually, this brings up some significant questions. Historically,
Solaris used an SCM where each new release started at a new "root". In
the past, this "new root" was created at some point (in some cases many
months) in advance of the GA of the previous release.
onnv has not ever had a "branch" or "fork" that would serve as prior
art. There has always been just the head.
I think that as Solaris 11 (for example) nears a time when it needs to
be stabilized, a branch (or whatever the hg analog is) needs to be
created, and Sun (or whomever) can do restricted fixes and such from
that branch, without forcing active development on the trunk to cease.
Other distros could do the same.
I think it is also reasonable, to have some kind of planned
stabilization time in the trunk, because it will minimize effort that
Sun (or other distributors) have to spend backporting and merging in
fixes from the trunk into their release branches. It could also, I
think, serve to focus some engineers on taking that time to address
quality concerns rather than new features. (Everybody loves new
features, but some attention has to be paid to fixing outstanding bugs.
Sun's own sustaining engineering does much of this, but I think it would
be helpful to encourage community participation here as well as in the
creation of new features.)
In short, I like the proposal, but I would like to see how Sun plans to
deal with branching (or otherwise handling) stabilization of Solaris 11
vs. continued development on Solaris 12.
-- Garrett
>
> -- Rich
>
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
