On Tue, Oct 06, 2009 at 12:18:21PM -0600, Jerry Jelinek wrote: > Peter Memishian wrote: >> > also, i would have though you'd commited to doing this work when you >> > decided to fork the sn1 brand code instead of making it common. >> >> I was wondering about this too. Indeed, there seems be a sizeable amount >> of duplicated code now. Why is this the right design? > > Because the sn1 brand is an internal brand for testing > and is not delivered to customers. Once the solaris10 > brand is integrated, the sn1 brand will no longer serve > its original role and could even be removed from the source > tree if we wanted to. >
really? i'd have to disagree. i was actually expecting that when nevada dies we'd have to update the sn1 brand to work on opensolaris. i always thought you forked the code because that was faster than re-factoring it to be common. the sn1 brand is still the ideal method for testing the brandz framework itself. using the s10 brand to test the brandz framework is ok, but then you're also testing the s10 emulation layer, and that emulation is far from complete. (witness all the currently unsupported s10 functionality.) as an example, take a look at todds current bug. from todds (a developers) perspective, i think it'd be much better to reproduce the problem, debug it, fix it, and test it on the sn1 brand than on the s10 brand. the sn1 brand makes brandz framework development and regression testing easier for developers. (it's actually a bug, and a dis-service to ourselves, that we never integrated it into our automated zones testing.) the fact that the sn1 code is also for the most part duplicated in the s8 and s9 brands is also lousy. hopefully no one ever makes a successfull business case for porting those to opensolaris. ed _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org