Nicolas Williams wrote:
> On Tue, Sep 01, 2009 at 09:21:09AM -0700, John Plocher wrote:
>
>> On Mon, Aug 24, 2009 at 10:15 AM, Nicolas
>> Williams<Nicolas.Williams at sun.com> wrote:
>>
>>> Banishing would-be Volatile stuff (e.g., because we have no i-team
>>> committed to supporting it) to /contrib won't absolve us when the
>>> upstream community breaks compat and we blindly ship the broken
>>> version.
>>>
>> I believe you might be making an invalid assumption - that
>> incompatible changes in a component are somehow automatically and
>> always an indication of brokenness.
>>
>
> Actually, I wasn't. The points of my two posts in this sub-thread were:
>
> - The ARC should stay out of design issues (in this case the design
> issue of using Tcl to configure shell environment modules);
>
Why? If the design imposes upon the consumers, then ARC should be
concerned. As a specific case here, Tcl imposes two things on consumers:
1) a scripting syntax/language heretofore not used for core system bits
2) a dependency on the Tcl packages itself.
Both of those considerations fall, IMO, well within ARC oversight.
> - /contrib is a not good place for Sun projects to integrate into --
> aim for /dev & /release if you can;
>
Why? I think /contrib is perfectly reasonable for projects that just
want to enable something, and don't want to make support guarantees. We
have no other way to deliver 'caveat emptor' bits that I can see. If
/contrib works for the rest of the community, why not also Sun?
> - What is the architectural status of /contrib? IMO: none. /contrib
> is for third party contributions that are not yet ready to integrate
> into /dev & /release;
>
True. Or things that don't need/want to integrate into /dev or
/release. For example, joe random software package that someone sets
up, but doesn't want to commit to sustaining forever.
> - What to do about FOSS backwards compatibility breakage? (This was in
> my follow-up.) My suggestion: documented stability levels can and
> should be used to set expectations, but we need to be much more
> flexible with respect to backwards compatibility, and for the reasons
> that you pointed out (i.e., we're in violent agreement).
>
Yes. I'd like to point out that FOSS gets a special exception when it
is delivered strictly for FOSS compatibility. I think that exception
goes away when we start using it as a building block for our own
architecture pieces. I.e., its bad if project team A delivers a new
version of a package that breaks project team B.
> Specifically, IMO: we should have very frequent Minor releases, or at
> least treat releases as "Minor for some things, Mico/Patch for most
> things", or otherwise allow for out of cycle breaks, plus suitable
> warnings on breaks.
>
This topic is not a matter for ARC to decide. Release timelines are
decided by the PAC and business teams. ARC can however relax some of
the breakage rules. We've already widely done that for a number of
items in Nevada/OpenSolaris.
> Alt. description: keep existing ARC interface taxonomy, but make it
> easier to make out of cycle breaks by adding to the release binding
> taxonomy.
>
I'm not sure how that will help. Release taxonomies need to follow user
expectations. Otherwise they become useless. (By that I mean, a
"minor" release needs to be associated with a real versioned product, so
end users know where the boundaries are.)
>
>> The job of the ARC is to balance these conflicting requirements in a
>> way that does the least violence to the players - ...
>>
>
> Yes. But with the current rules the ARC continues to strongly favor
> committed interfaces and backwards compatibility. I-teams therefore
> tend to prefer going with Volatile. But Volatile isn't useful for
> setting expectations. Committed and Uncommitted are, but they are too
> strong too. It ought to be possible for an i-team to go with Committed
> or Uncommitted if they believe some FOSS is stable (e.g., APIs from MIT
> krb5) and still make out of cycle backwards incompatible updates when
> the upstream community does it, there's no funding to avoid the problem
> the old-fashioned way.
>
We used to have better ways of expressing this. Like "Evolving". But
folks decided that the fine grained stability levels were not useful.
I'd really like to have something like "External", which would mean that
Sun (or the Solaris org) makes no guarantees about interface stability,
we just follow the upstream. Caveat emptor sort of thing.
> The vast majority of the time upstream will manage to stay backwards
> compatible, so the majority of the time Committed and Uncommitted will
> be much more useful than Volatile.
>
It only takes one nasty breakage to be really annoying. And it depends
on your upstream. Some are pretty good at understanding binary
compatibility. Others, much less so. (OpenSSL, I'm looking squarely at
you.)
>
>> ... The question isn't "should we provide a new
>> version?", but rather "how can we provide a *set* of versions that can
>> be used to meet the various needs articulated above?".
>>
>
> Sometimes you get into DLL hell if you provide multiple versions. At
> least with direct binding that's less likely than it used to be.
>
> We might even need to deliver more than two versions of some FOSS.
>
This way generally lies madness. There are some specific counter
examples were it has worked out (multiple perl versions for example),
but doing this generally for shared libraries will cause huge kinds of
problems.
I don't care what crapware we import for end-users to use at their own
risk; but if we ought to be *architecting* things so that the bits we
rely on and use are not subject to constant or unplanned breakage.
Put another way, IMO a project that is a "leaf project" (no dependents)
can do whatever it wants as long as it sets end-user expectations
appropriately.
But a project which becomes a building block for other systems (e.g.
OpenSSL) needs to be much more carefully managed. We do everyone a
disservice by just ignoring the problem or punting on it by delivering
multiple library versions without good planning/architecture.
>
>> The easy case is when a component evolves in only compatible ways.
>> We've got that idiom nailed. Now we need to expand our abilities to
>> encompass the not-so-easy cases.
>>
>
> Yes.
>
> The practically inescapable conclusion is that we should just allow out
> of cycle backwards incompatible changes (after some teeth gnashing,
> perhaps),
This has already happened for specific cases. I think its OK but it
needs to be an exception and such cases carefully reviewed for impact.
> with suitable warnings, and preferably have frequent Minor or
> Minor-for-some-things (and even Major-for-some-things) releases.
>
As already indicated, release schedules are far outside of ARC control.
Having release taxonomies track something *other* than actual product
release boundaries just makes them useless, so I can't support such an idea.
- Garrett
