Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]

[James Carlson]

Jyri Virkki writes:
> At some point there's going to have to be either a new intermediate
> level or some different interpretation, given that neither of these
> two we have today applies sanely (ha ha) to the vast majority of these
> open source projects being integrated.   

An intermediate level *where*?  Between Volatile and Uncommitted?

I don't see how that helps.  In fact, I think that'd make things
dramatically worse than they are today.  I'm beginning to believe that
the only way out of this mess is to eliminate Volatile from the
taxonomy, as a substantial majority of the uses of it seems to
represent abuse.

The underlying issue is that we're consistently misrepresenting our
delivered product because of a persistent misunderstanding of the
nature of open source itself and of open source development.  I don't
think that the ARC can fix this, but it ought to at least put a stop
to it.

The stability levels have nothing to do with "control" over the open
source code itself, and I suspect that's at the core of the
misunderstanding.  They have everything to do with correctly
representing what we *deliver*.  Those upstream providers don't force
new binaries onto our DVDs or web sites; we do that.  We need to
document what we're putting there -- or we just shouldn't be in that
business.

In fact, most open source projects I've dealt with are either keenly
aware of the stability issues, or are quite stable and dormant, or are
so hemmed in by their own popularity that they can't make incompatible
changes even if they wanted to.  Slapping them all with the pejorative
"Volatile" label is wrong.  It misrepresents what they deliver and
creates havoc for consumers who will be forced by the ARC to prepare
for changes that will simply never arrive.

Are we just dumping bits over a wall or are we trying to build a
system?

Lei Chen writes:
>       I think I'd better copy my reply to this alias, in order not to 
> cause confusion of my expression in last email. Sorry for duplication.

I already responded privately.  A summary here.

> Thank you for the explanation. I'm happy that's also my understanding of 
> these two glossaries. Maybe my expression of "use" causes the confusion. 
> By "use", I meant to say that if a user, like GIMP, wants to use 
> libsane, it also has to sign a contract for Uncommitted interface, as 
> for the Volatile interface.  "The opinion allowing any project to import 
> an Uncommitted interface must explain why it is acceptable, and a 
> contract must be put into place allowing this use", cited from interface 
> taxonomy[1].  Please correct me if I'm wrong.

With a plausible explanation of how changes are properly dealt with on
a Minor release boundary, and how the builds themselves don't just
start falling apart, I think I could be happy with a case that had a
dependency on an Uncommitted interface.  It depends entirely on
context and the details of the situation.

Uncommitted is *far* better than Volatile.  It restricts chaos to the
Minor release boundaries, which are much less frequent than the rate
at which we ship patches.

> Since the SANE is from an open source community and not controlled by 
> Sun, I will update the proposal to promote its stability to Uncommitted 
> if other projects can easily import SANE. What's your opinions?

"Control" of the upstream source has nothing whatsoever to do with the
problem.  Using that as an excuse to force the advertised stability
artificially low does a grave disservice to all who consume those
interfaces.

If that's really the best we can manage, then I'd rather see us give
up on architectural review.  I think it'd be preferable to do nothing
than to turn the process into a farce.  At least we won't be
misleading anyone when we say nothing at all.

-- 
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