>>>>> "RL" == Richard Lowe <[EMAIL PROTECTED]> writes:
RL> does on+2 appear far enough before on+1 is done that none of these RL> will be problematic? It can, and that's what we've usually done in the past (i.e., when Solaris development was closed). Opening on+2 sooner means taking the on+2 gatekeepers away from other work, but it means ready-to-go code won't rot. I don't know of any magic formula that tells how to manage that tradeoff, so it's mostly been (AFAICT) a judgement call by senior engineers and management as to when to open the gate for the next release. The other tradeoff is how to manage fixes that go into on+1. That is, if I commit a fix to on+1, do I also commit it to on+2, or does the on+2 gatekeeper pick it drops from on+1 and do the merge? The first approach is more work for me (which means I'm not working on other on+1 stoppers); the second approach increases the risk of a mismerge. One hybrid approach would be for the gatekeeper to do the merge, but the gatekeeper calls me in to assist with the merge if it's not straightforward. RL> Do people care enough about the light restriction for a 10-like RL> cycle to actually be a problem in that way at all? I think that for little stuff (most notably minor RFEs), the light restriction phase is not a problem. If people don't make the cutoff, they put the code "on the shelf" until a gate is ready to take it. If the fix is small enough, it's unlikely to rot much while waiting for an open gate. Large projects are a little more interesting. If you putback just before a restricted period, the restricted period needs to be long enough to stabilize the release (i.e., discover and fix bugs that the change introduced). If you putback into on+2 while on+1 work is still going on, merging the on+1 changes into the on+2 gate gets a lot harder. If you have a long restricted period where the code has no place to go, it's a lot harder to avoid bitrot than it is with a small RFE. One of the ways we've managed large projects in the past is to fiddle with the schedule, e.g., delaying the cutoff (and subsequent release date) to accomodate a "must have" project. I suppose that approach could be used for OpenSolaris, but we'd want some sort of vendor-neutral way to determine what's a "must have" project. RL> The above is all assuming that onnv and onnv+1 will be visible to us RL> concurrently (and similar for onnv-patch/on11-patch, probably). Right. Another possible approach is to have a single OpenSolaris gate (well, one per consolidation). Each distro would create its own stable branch when it gets close to a release. (That branch could still be visible, but it would be run by the distro, not by the community.) If OpenSolaris has releases, then in addition to the transition issues (from one release to the next), we also need to figure out how older releases are managed and eventually retired. Do any of the distros besides Solaris plan to issue patches for old releases? If they do, then there's some benefit in having a common source base, though I can imagine policy conflicts over what's worth patching. mike _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
