[jumping in late...]

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.

Much of the historic ARC focus has indeed been on how to evolve things
in compatible ways so that dependency stacks don't get unexpectedly
broken.  This view is a natural one if one looks at the OS+apps as a
self-contained ecosystem, which is exactly what Solaris and its
bundled packages was - before FOSS.

Nowadays, the ecosystem is much larger.  It consists of windows,
linux, *bsd and *solaris systems, all trying to be good platforms for
running FOSS projects that are being developed elsewhere.  In this
brave new world, when a 3rd party FOSS component swerves wildly to the
left, it is the conservative platforms who resist that change that are
seen as buggy - or at least not being on top of things.  When your IT
department has a mix of platforms and users who want the latest FOSS
whatchamacallit, compatibility takes on a new meaning:  it is no
longer sufficient to be the same as yesterday, it now needs to be the
same as the upstream source that is being deployed on all the other
platforms.

The job of the ARC is to balance these conflicting requirements in a
way that does the least violence to the players - middleware and
platform developers need predictable foundations, our customers/users
need the ability to manage the migration between versions at their own
speed, and early adopters need to be able to get and use the bleeding
edge latest stuff.  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?".

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.

   -John

Reply via email to