tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Feng <enjoyj...@gmail.com>
Subject Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet ready for release
Date Thu, 01 Jul 2010 14:46:53 GMT
+1. Good catch for samples and tests.

Sent from my iPhone

On Jul 1, 2010, at 4:10 AM, Simon Nash <nash@apache.org> wrote:

> I'm OK with all of this.  I believe the implication (not stated explicitly)
> is that everything in "modules" needs to be included in the main build.
> I think this should be a requirement, and anything that isn't ready for this
> should be under "contrib".
> 
> Also, I'm not sure how this affects the contents of "samples".  I just
> came across two recently added 1.x samples that aren't in the build, and
> one of these can't be added to the build because it isn't buildable.
> I think we should treat "samples" in the same way as "modules", which
> would suggest the following structure:
> 
> trunk
>  modules (for release, all in the build)
>  samples (for release, all in the build)
>  etc.
>  contrib (excluded from release profile)
>    modules (not for release, some in the build)
>    samples (not for release, some in the build)
>    etc.
> 
>  Simon
> 
> Simon Laws wrote:
>> Good ideas Raymond. Small comments in-line
>> On Thu, Jul 1, 2010 at 8:11 AM, Raymond Feng <enjoyjava@gmail.com> wrote:
>>> IMO, we could have the following categories:
>>> 1) Sandbox: crazy ideas or something that don't have consensus yet in the
>>> community (You can do whatever you want here :-)
>> +1
>>> 2) Trunk/contrib: experimental features that are not ready to be included in
>>> the next release
>>>     a) If the code can be built, the module should be included in the main
>>> build
>> +1 at the discretion of those working on the module. I.e. if it builds
>> but you want to exclude it then no problem.
>>>     b) if the code cannot be built, the module won't be included in the
>>> main build
>> +1
>>> 3) Trunk/modules: stable features that are ready for the next release
>> +1
>>> Developers can adjust things between 2.a and 2.b.
>> +1
>>> We should promote things
>>> from 2 into 3 when the features are ready.
>> What does "we" mean here. Presumably developers working on modules can
>> do this when they feel ready.
>>> We should always try to ensure the features included in the build passing no
>>> matter if they are from "contrib" (2.a) or "modules" (3). The default maven
>>> build profile should include both "contrib" and "modules".  The release
>>> profile will exclude "contrib". When we cut a release, the "contrib" will be
>>> excluded from the distro.
>> +1
>>> Mostly, I prefer to have a "SOFT" separation between the experimental and
>>> ready-for-release features.
>> Me too.This kind of approach at least gives the developer the ability
>> to develop in the trunk while giving the RM a clear steer on what is
>> in the distro.
>>> Sent from my iPhone
>>> On Jun 30, 2010, at 10:47 AM, Simon Laws <simonslaws@googlemail.com> wrote:
>>> 
>> Simon
> 

Mime
View raw message