> Thus spake Bernard Li ([EMAIL PROTECTED]): > >Hey Brian: > > > >I was testing 3.7.0 and have fixed some bugs in my local > repository and am ready to check them in. Please let me know > if it is okay for me to do so. > > I would send them to me as patches at this point, as I'm considering > that branch my own private playground. I want others to see > it, but it > may be out of sync with what's on my machine.
Okay, I will submit them as patches then... > >The code can automatically detect my network card, however, > the node I ran si_prepareclient has a SCSI HD but the node > I'm trying to image has IDE HD, therefore /dev/hda isn't > present. When I manually create the block devices (mknod hda > b 3 0, etc.) get_arch would hang... I have reported this > previously, any ideas why? > > > >BTW, do you plan to merge si_mkbootpackage with > si_prepareclient? I am using si_prepareclient right now > because you mention that it works, however, I think the > "correct" way for me to generate the boot binaries (for my > scenario) should be si_mkbootpackage. > > I think that makes sense. Once everything works properly with > si_prepareclient, then yes, I think it makes sense to make > si_mkbootpackage work the same way. Sounds good. > >Can you please let me know what you plan to do in terms of > merging the branch with trunk, etc.? Right now we have been > checking code enhancements to trunk, but other branches (eg. > your 3.7.0 branch) do not have them. How do you plan to merge? > > Once I get my private branch working properly, I plan to warn everyone > on the devel list, then merge back into trunk. > > > >For OSCAR, what we usually do is if we check something into > a branch, you would also check them into trunk (if they are > relevant). This seems to work pretty well and usually does > not require any "merging" of code since the code is already > present in both branch and trunk. > > The method you describe takes a lot more effort, and may lose certain > history information that is retained when you do a merge. It's also > prone to failure, as it relies on people remembering things > -- to check > code into two places at once. That is, someone might forget to > double-commit a certain patch. Okay, I'd like to see how this turns out and learn from the experience. Just FYI (you probably already know anyways), there is code skew between branch-3.6.x, trunk and tag-3.7.0... Do we need to do anything special to keep track of the differences? Cheers, Bernard ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Sisuite-devel mailing list Sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
