> > I don't see how that addresses the primary point, which is that Solaris
 > > brands seem to suffer from code duplication.  Are you asserting that the
 > > amount of code duplication between the sn1 and solaris10 brands is unique
 > > to that situation and is not something that will occur again when we cons
 > > up the next solarisX brand?
 > Yes.  If we were to ship another brand that was
 > fundamentally similar to the solaris10 brand (e.g. the solaris9
 > brand on Solaris Next), then I think it would make sense for
 > that project to try to make more of the code common with the
 > then currently shipping solaris10 brand.  However, I don't think
 > that is necessary for a brand we don't ship (but I can also
 > understand if you don't agree with me).

Indeed, I don't agree, for three reasons:

   1. You are establishing a precedent that the way we develop new
      Solaris brands is via cut-and-paste in a manner that's expedient for
      the implementor.  When the next brand comes along, this existing
      example will likely be used as justification for why they should not
      be "burdened" with the task of properly factoring the software.

   2. Shipping or not, the sn1 codebase is still part of our product
      and needs to be maintained.  By forking the source, we are 
      doubling the cost of that maintenance and making it easy for things
      to get out of sync (and indeed, the tax of maintaining these
      parallel brands has already started to be levied before the
      solaris10 brand has even integrated).  We've all seen this many
      times but yet we keep doing it.

   3. It is precisely because of our limited resources that we must
      adhere to best practices and commonize code rather than fork it.

All that said, ultimately this is an issue for you and the rest of the
zones team to resolve, so I'll bow out of this, but I strongly disagree
with the approach that's been taken.

zones-discuss mailing list

Reply via email to