Danek Duvall writes: > As for maintenance burden, my concerns are around testing. As it is, I > generally have to test components on the sly. In most cases, the only > testbed I have is the live gate, and the only way to do that testing is by > modifying files in-place, waiting for an event to verify that the change > was correct, and either tweaking the changes or checking in the code (yes, > they already are under SCCS, though not teamware, control) depending on > success. Ugly, yes, but anything else means fully duplicating the gate > somewhere, and we just don't have the resources for that.
What would stop you from doing the same thing under SCM? The way I'd expect you'd do this is by creating a local hg clone, make the changes you want to try out, test your changes by copying them into the "official" locations (outside of SCM and with the 'x' bit set), and then (when everything is right), go through the process that leads to a commit. Yes, I know that the location of the source file in the gate is currently the same path that's executed by default, but I don't think that's actually a necessary condition. It might not even be a good thing. > the reviewer). 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? In my mind, 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. > 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. > The other tools in the gate are a bit different -- they're primarily for > use by developers in a development gate. Yeah, sure, gatekeepers use > nightly and protocmp and mkbfu and the rest, but not as a gate management > function (in fact, I'm discovering that nightly is downright broken when it > comes to managing a gate on ZFS). These tools are more limited in scope > than gate management tools, applying only to ON (and ON project gates) and > ON-like gates, which, AFAIK, is NWS and SFW. Also TLC. > 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. :-/ -- James Carlson, KISS Network <[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 _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
