From incubator to greenhouse to trunk

Like any large scale open source project Scala faces the problem how
contributions can be best integrated into the code base. Integrating
them too fast risks instability, and lack of common vision.
Integrating them too hesitantly risks stagnation and turning valuable
contributors away.

To address this problem, we have decided to work with a staged
approach, involving a Scala ``incubator'' and a Scala ``greenhouse''
as two stages for extensions and possible future additions to the
standard Scala distribution (named ``trunk'' in the following).

The incubator was launched some weeks ago by Miles Sabin. It's purpose
is to be a highly visible hosting platform for Scala projects that
should have widespread appeal and that are possible candidates for
future inclusion in a Scala release. Projects in incubator go each at
their own pace. Typically each project has one or more owners,  but
there is no central instance that controls what goes into incubator
overall (except for making hosting arrangements). Two projects have
already started up: I/O, led by Jesse Eichar, and modularization,
led by Josh Suereth.

The greenhouse is more centralized. It's role is to serve as a
concrete candidate for an alternate version of trunk which usually
includes the standard Scala distribution as a subset. Greenhouse code
is not yet cast in stone but is expected to build at all times and to
perform as well as trunk. There will be frequent merges of the latest
trunk with greenhouse code and there will be nightly builds.
Greenhouse jars will be made available from EPFL alongside
the standard distribution. There will also be regular assessments to
decide which parts of greenhouse are ready to be promoted to trunk.

The delta between greenhouse code and trunk code can be very flexible.
Some parts of greenhouse might introduce a whole package hierarchy,
where others could just add a couple of methods to existing trunk
classes.

Greenhouse has a ``gardener'', who acts as a central owner, deciding
what goes in, and who makes sure that everything works smoothly
together. Paul Phillips has agreed to serve in that role. He will
certainly need help, and I assume he will also delegate the
development of some parts to others, but he'll keep the final say of
what goes in.

In a sense, greenhouse is intended to recreate some of the feel of the
early days of Scala when development could be rapid because decisions
could be easily changed later on. With trunk that's now more difficult
because of the large and growing base of installed code. But if you
want to live a bit on the bleeding edge and value cool features over
100% stability of APIs you might well want to choose to build your
project on greenhouse instead of trunk.

By contrast, incubator casts a much wider net, combining projects that
will migrate to greenhouse/trunk alongside projects that will continue
to exist as separate entities.

So I believe both these efforts are ideally complementary, and I hope
that they will be enablers for lots of great contributions to the Scala
eco-system. Many thanks to Miles and Paul for running these efforts!

Cheers

 -- Martin