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

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

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.

zones-discuss mailing list

Reply via email to