Mailing-List: contact dev-help@tuscany.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tuscany.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4C2C77BA.7080408@apache.org>
Date: Thu, 01 Jul 2010 12:10:50 +0100
From: Simon Nash <nash@apache.org>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: dev@tuscany.apache.org
Subject: Re: [DISCUSS] Adding new function to the Tuscany trunk that's not
 yet 	ready for release
References: <AANLkTinBHY1Wazhj7Y81e6MS3CXknPpGOdu8kkVyzPe6@mail.gmail.com>
	<6F3FEC9D-96F9-4B50-863D-203AB0EFEE56@gmail.com>
 <AANLkTik_M18QCPsLUMrp4ok0DzHqG-oW2TgEupbdqOyL@mail.gmail.com>
In-Reply-To: <AANLkTik_M18QCPsLUMrp4ok0DzHqG-oW2TgEupbdqOyL@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>