Mark Logan writes:
> I only buried ntfsprogs because I thought it would be easier to make it 
> through PSARC that way. I guess I miscalculated. I did not hack 
> ntfsprogs at all, it was the easiest thing to port. I have no problem 
> delivering ntfsprogs in its entirety and in /usr/bin, if that is the 
> consensus.

Thanks; I think that's a big improvement.

For what it's worth, "making it through PSARC" is not the best
approach to take.  ARC review is a peer technical review, just like
code or design review.  The fact that it has some formal
infrastructure support is just thanks to some long-ago forethought
about the problem.  It could have been done for other reviews as well.

The best way to manage it is to make good engineering choices, then
explain what you're doing, just as you'd do for any other review.  If
that means you're delivering two or three or twenty separate FOSS
packages in a single project, then that's fine.  Do it if it makes
sense.

> Also maybe I need to rethink the Volatile stability. I wrongly assumed 
> that FOSS had to be Volatile. Also the goal is to get the OpenSolaris 
> installer to use either Parted or GParted, their choice, so I need to 
> choose the correct stability to achieve that.

If it's the GUI that they'll use, I'd expect that all you need is to
have the path name '/usr/sbin/gparted' made Committed (probably not
this case).  If it's the command line, then it's '/usr/sbin/parted'
plus perhaps one or two of the command-line options.

In any event, choosing stability level is always a mixture of things:

  - How often it's expected to change.  (For many things, this can be
    inferred from how often it has changed in the past.)

  - How much change is expected.  (Just little tweaks and new features
    each month, or major breakage every other day?)

  - How you'll deal with change.  (If they break it upstream, do you
    want to fork?  Help them fix it?  Freeze our delivered bits and
    never upgrade?  Or just deliver the brokenness to your users?)

  - How your customers or users will deal with change.  (Is someone
    building software on top of it?  What individual parts do they
    depend on?  Are there any parts that are unimportant and thus
    changeable?)

The *one* thing that isn't in that mix is the author.  Interface
stability and thus architectural review doesn't depend on who wrote
the code.  "FOSS" and "Volatile" really have little or nothing to do
with each other.

(In fact, it was the conflation of "Open Source" with "External" in
the old taxonomy that forced us to rewrite it and invent "Volatile."
It's a little disheartening to hear that the same aliasing is going
on.)

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to