Richard Lowe writes: > > The interesting question then is how does code get from this "beta" > > workspace to the production-ready gate. Our experience with merges is > > that project team does a better job than third parties when it comes to > > merging their changes into another workspace. So I'm not enthusiastic > > about the "cherry picking" model. [...] > (and yes, there's a whole lot of "how would this work without doubling the > amount of effort required?" handwaving going on on my part, too).
I think the handwaving that bothers me is "how would this lower-quality (or 'not yet finished') gate be kept sane?" The reason we have the rules around the main gate is to avoid the Quality Death Spiral. Why would the new LQ/NYF gate not succumb to dozens of partially-functional projects that drag the whole thing to its knees? How would anyone use bits produced by this gate? More importantly, perhaps, how do you deal with overlaps? It's commonly the case that multiple projects must touch the same files; often in non-trivial ways. We handle this today by serializing integrations into the main gate. Code that lives in the separate gate will have to deal with differences between this gate and the main gate, both at the time it integrates to this separate gate and (later) when it migrates over to the main gate and some of the changes "disappear." The tests done on the previous bits may or may not have anything to do with the final ones. Ultimately, what I think you're actually describing is a separate release train, where what we currently think of as the "marketing release" is placed on ice and allowed to gel. The new release just has lower quality goals (e.g., not caring about i18n). -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
