Mike Kupfer wrote:
"RL" == Richard Lowe <[EMAIL PROTECTED]> writes:
MK> So I suppose someone could propose a project which just takes other
MK> stuff and integrates it for people to play with.
RL> Projects are projects, I don't immediately think I have any specific
RL> problem with a *project* that pulls in code from various other
RL> projects, or the like. But I'm strongly opposed to the *gate* being
RL> a mishmash of such things.
What's a gate, other than a workspace that's run a certain way?
I was saying "The" not "A". Intending to suggest "The main MarketingRelease
gates".
Prior to OpenSolaris, there have been ON projects that kept a workspace
containing their project plus at least one other large project that was
going on at the same time. (For example, IIRC, you could get BFU
archives with pre-integration DTrace bits plus pre-integration something
else.) What I'm thinking of is a generalization of that approach. I've
hand-waved on some important decisions, like how to decide what to take
and what to leave out. But those decisions belong to whoever is running
the project.
Exactly, I think that could be fine run as a project, but parts of this
thread seemed to suggest substantially lowering the standards required for
putback to the MR gates, and following this idea with the primary gates.
RL> At various points in these threads people have suggested that
RL> lowering standards would be helpful, or even would be necessary. I
RL> disagree with that entirely.
I think there needs to be space for stuff that's solid enough to be
useful, but maybe not as polished as we'd like for final integration
(e.g., not fully internationalized). It's an opportunity for projects
to get testing and feedback, earlier, when they're in a better position
to take advantage of it. Of course, projects could also get that
feedback without a "beta" integration workspace. But I'm expecting
they'll get wider exposure if there's a single download, so that users
don't have to pick and choose from multiple project web pages.
From what I can tell, you're agreeing with what I intended to say, but
using far more precise wording. :)
I think space for this stuff before it's ready for final integration is a
fine idea, and most likely a good idea. I'm saying that accelerating the
final integration is bad.
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.
I would hope the same as now, the project team does the merge(s) and puts it
back when appropriate.
To be more precise about it. I think I like the idea of the "beta"
workspace you're talking about here, I don't feel it's a substitute for the
primary gate (or the gate a substitute for it), nor another path through the
workflow. The project team should be responsible for their integration to
both, they should only integrate into the "main" gate under the same
conditions they would now.
Does that make more sense than my first attempt at saying it?
(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).
-- Rich
_______________________________________________
opensolaris-discuss mailing list
[email protected]
