Joseph J. VLcek wrote: > Thanks for the feedback Dave. > > Glenn may have more comments... Mine are below. > > Joe > > Dave Miner wrote: >> Glenn Lagasse wrote: >>> All, >>> >>> I've posted the first rev of the design document for the Virtual Machine >>> Constructor project at the following location: >>> >>> <http://www.opensolaris.org/os/project/caiman/VMC> >>> >>> Please provide any comments you may have by COB Friday, July 31st. If >>> you need more time to review the document, please let me know. >>> >>> Thanks, >>> >> >> General: section numbering would be helpful in providing review >> references. >> >> VMC DC Manifest: Please consider making these new tags arguments to >> the finalizer scripts instead. The DC manifest language seems >> somewhat too application-specific when viewed in the context of the >> unified engine work, and I'd like to see a moratorium on additional >> tags until that's been sorted out some. If that's not practical for >> some reason, consider at least introducing a new section specific to >> this application of DC to group these tags within so that the clutter >> is somewhat confined. > > I like the suggestion of having the tags be arguments to the finalizer > scripts instead. It has the side effect of easing the development of > them since I can test them without a manifest. > >> >> Finalizer scripts: Please add notes on why ksh is chosen for these >> vs. other possible choices (at least python). Well, I see later on >> that you have notes about this in the phasing, but I'd expect it here >> where the decision is noted, or at least a reference. > > Sure. A reference where the decisio is noted would make it clearer. > > >> >> Phasing: Since it appears that the bootable AI image work will be >> integrated well before your anticipated integration, does it really >> make sense to deliver phase 1 as specified here? > > Agreed. I didn't think we need to deliver Phase I. I had thought that we > could check in the finalized scripts as Eric had pointed out checking > code in would be a good way to show progress. Perhaps this is not > necessary. ? >
Checking in incomplete functionality to a tree that is effectively operating as a consolidation is usually undesirable, as it's unclear to other developers and users what the state of it is. Showing progress for this project, if that's necessary, could perhaps be done by making early binary wads available or something of that nature. Dave
