>>>>> "Jim" == James Carlson <[EMAIL PROTECTED]> writes:
Jim> I think the handwaving that bothers me is "how would this Jim> lower-quality (or 'not yet finished') gate be kept sane?" That's somewhat deliberate on my part. People who dislike the current ON policies would be in the position to try out alternatives. If something works well, the ON gate can adopt it. Jim> Why would the new LQ/NYF gate not succumb to dozens of Jim> partially-functional projects that drag the whole thing to its Jim> knees? There's a risk that this could happen, but I don't think it's a foregone conclusion. Whoever runs the NYF gate will have to find a balance. If things do fall apart, it doesn't affect the product gate. And it'll provide a data point that we as a community can learn from. (Ditto for an "anything goes gate" if someone is crazy^Wbrave enough to set one up.) Jim> More importantly, perhaps, how do you deal with overlaps? It's Jim> commonly the case that multiple projects must touch the same files; Jim> often in non-trivial ways. We handle this today by serializing Jim> integrations into the main gate. Which we would continue to do. Integration burden would be on the project team. The project team would look at the contents of the NYF gate and decide if the additional exposure merits the burden of keeping two versions. If the NYF gate doesn't diverge too widely from the product gate, the burden is relatively light. Jim> Code that lives in the separate gate will have to deal with Jim> differences between this gate and the main gate, both at the time Jim> it integrates to this separate gate and (later) when it migrates Jim> over to the main gate and some of the changes "disappear." The Jim> tests done on the previous bits may or may not have anything to do Jim> with the final ones. Yeah, that's a point. Testing under the NYF gate might only provide "partial credit" towards integration into the production gate, because it would be hard (in the general case) to separate out the impact of other projects in the NYF gate. For putbacks to the product gate, we'd probably want test suite runs to be done using a child of the product gate. Jim> Ultimately, what I think you're actually describing is a separate Jim> release train, where what we currently think of as the "marketing Jim> release" is placed on ice and allowed to gel. The new release just Jim> has lower quality goals (e.g., not caring about i18n). I agree that there's a risk that project teams will decide that they're done once they're in the NYF gate. And if the non-Sun distros start basing off the NYF gate, rather than the product gate, we would have a de-facto competing train. But in that scenario what we'd have is basically a fork, which has been a risk since OpenSolaris first launched. mike _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
