On Wed, Dec 06, 2006 at 01:51:18PM -0500, James Carlson wrote: > What would stop you from doing the same thing under SCM?
It already is. Only, like you said, it's just not copied from a source location. I think, though, that separating the deployment from the development may make sense here. What I was getting hung up on was that before you can make a change to a file in the gate, you have to test (if you're using RTIs, at least), but I can't test without making a change to a file in the gate. Splitting it out makes sense. You could even collapse the two again, by saying that you can't commit a change until it's tested, even if the file you're testing is in the repo itself. But I've no particular attachment to that. Any way I look at it, it's a bit of a confusing development/deployment scenario -- either it's overly formal and files need to be copied from the dev tree to the live tree, or there's confusion about how the RTI process applies. > > And what do we do when we're in a code freeze, with two reviewers > > required, and all RTI's going through the tech lead? Should the gate > > management code be frozen as well? Does that make sense? > > No, it doesn't make sense. But I don't see why it'd be necessary, > either. > > Updating these files is roughly equivalent to updating the local > usr/src/doc or usr/src/bugs directory that many ON-child projects > maintain -- no extraordinary review process is necessary because it's > not the system source code. Except that we're talking about putting this directly in ON. ON has a single review process for all files, no exceptions. I don't think changing that policy is in scope here. > > I absolutely see the utility of having many, if not all of these tools > > generally available, but I don't think this is that project. Regardless, I > > also believe that the gate management tools should be in their own repo; > > projects such as ON can build on these tools by extension and subclassing, > > but embedding them in ON binds them too tightly to the one consolidation. > > It depends on whether the tools need to evolve with the gate itself. > > If not -- if they're really indendent of the gate -- then keeping them > in a separate repository sounds like a fine idea. I don't see that they need to evolve with the gate, no. They're related, but not intimately (no "Consolidation Private" interfaces are used, to my knowledge). > > So while they don't totally > > belong in ON, they at least have some of that tight binding. > > Actually, folks in other consolidations, such as Install, use 'wx' and > some of the other ON tools. Just with great difficulty. :-/ Which would be nice to fix, but not this discussion. Danek _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
