At 02:44 PM 11/23/2002, Brian Pane wrote:
>On Sat, 2002-11-23 at 12:19, Cliff Woolley wrote:
>> On Sat, 23 Nov 2002, Aaron Bannert wrote:
>
>
>> > >   +    * The 'modules/experimental' tree will evaporate soon.  Anything
>> > >   +      in the development branch should be located under it's eventual
>> > >   +      home (such as modules/cache/.)
>> >
>> > There's no reason to remove this from the 2.0 releases. They are
>> > experimental not matter way, and if someone grabs a 2.0 tarball and
>> > wants to start hacking on experimental stuff, all the better!
>> 
>> -1 to removing them from 2.0.  The modules are 'experimental' not just
>> because they are development projects, but more because we don't put the
>> same level of faith in those modules working as advertised as we do in
>> regular modules.  But some people are willing to take the chance and DO
>> use them in production!  We can't just snatch them out from under those
>> people.
>
>I agree: we should keep the experimental modules.
>
>The cache code is a good example of a beta-quality component
>that's getting a healthy amount of testing and feedback from
>users because it's available as an experimental subsystem in
>the stable release.

I think we have a universal consensus here about 2.0.

I'm not certain I want to persist the experimental concept into 2.2,
since those users who love "life on the bleeding edge" should be
encouraged to grab a 2.1 alpha or beta, and play with the modules
that are "almost ready".  I'd like to see us quit putting modules into
the next release branch that are "far from ready".

The other half of the coin; we want those users testing 2.1.  We think
2.1 is pretty cool.  We hope to have a stable 2.2 rollout without a ton
of bugs.  The more testers, due to their desire to test the latest and
greatest, or their desire to get 'experimental' features, the better for
the code we will release as 2.2.

Bill

Reply via email to