You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2010/06/30 19:47:59 UTC
[DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
In Tuscany there are no hurdles for getting new code into trunk.
However it would be easier, come release time, if we knew which
modules we're ready for release and which where not. Here "ready for
release" is in the eye of the developer(s) building the module in
question, i.e. there is no checklist or committee that determines it.
We do have a contrib directory [1] which I think (just my view)
*currently* fits into the grand scheme of things in the following way:
my sandbox - stuff I just want to work on
contrib - stuff that I think could go into a release at some point but
which isn't ready yet
trunk - stuff which I think is ready to release
I chatted with others about this and there were various opinions about
how we can improve so starting this [DISCUSS] to see if we can come to
some common understanding.
[1] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
Posted by ant elder <an...@gmail.com>.
On Sun, Jul 4, 2010 at 5:26 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Sat, Jul 3, 2010 at 1:11 PM, Simon Nash <na...@apache.org> wrote:
>> ant elder wrote:
>>>
>>> On Thu, Jul 1, 2010 at 8:41 AM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>
>>>>> 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.
>>>>
>>>
>>> Yes i think thats implied from all the previous discussions we've had
>>> around this, that has to be up to the devs doing the work.
>>>
>>> I'm not totally convinced about the need for a contrib folder in
>>> trunk. The point of it sounds like so that things can be removed when
>>> a release is done, but why remove things? I'd rather get feedback from
>>> users as soon as possible so prefer to include even work in progress
>>> items in releases.
>>>
>> Some reasons for not including these things in a release:
>>
>> 1. They might not be buildable.
>>
>> 2. The developer(s) might know they don't work, in which case getting
>> feedback saying "feature X doesn't work" wouldn't be very useful.
>>
>> 3. Users might expect that things in a release should work (at least to
>> some reasonable extent) and they might not be very happy to put time
>> into trying to use a feature and eventually find that the feature is
>> incomplete or not ready.
>>
>> Simon
>
>
> +1, users that really want to try bleeding edge features would
> probably be comfortable building and consuming trunk and provide the
> necessary feedback.. and we can always advertise these pieces via
> dev/user list, blogging, etc
>
I wasn't saying I'm against having a contrib folder in trunk if anyone
wants to try it, just not sure how much i personally would use it. All
those reasons for maybe using it could also be handled by just saying
its work in progress in doc/blog/mailing lists/build scripts etc.
...ant
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
Posted by Luciano Resende <lu...@gmail.com>.
On Sat, Jul 3, 2010 at 1:11 PM, Simon Nash <na...@apache.org> wrote:
> ant elder wrote:
>>
>> On Thu, Jul 1, 2010 at 8:41 AM, Simon Laws <si...@googlemail.com>
>> wrote:
>>
>>>> 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.
>>>
>>
>> Yes i think thats implied from all the previous discussions we've had
>> around this, that has to be up to the devs doing the work.
>>
>> I'm not totally convinced about the need for a contrib folder in
>> trunk. The point of it sounds like so that things can be removed when
>> a release is done, but why remove things? I'd rather get feedback from
>> users as soon as possible so prefer to include even work in progress
>> items in releases.
>>
> Some reasons for not including these things in a release:
>
> 1. They might not be buildable.
>
> 2. The developer(s) might know they don't work, in which case getting
> feedback saying "feature X doesn't work" wouldn't be very useful.
>
> 3. Users might expect that things in a release should work (at least to
> some reasonable extent) and they might not be very happy to put time
> into trying to use a feature and eventually find that the feature is
> incomplete or not ready.
>
> Simon
+1, users that really want to try bleeding edge features would
probably be comfortable building and consuming trunk and provide the
necessary feedback.. and we can always advertise these pieces via
dev/user list, blogging, etc
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not
yet ready for release
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Thu, Jul 1, 2010 at 8:41 AM, Simon Laws <si...@googlemail.com> wrote:
>
>>> 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.
>>
>
> Yes i think thats implied from all the previous discussions we've had
> around this, that has to be up to the devs doing the work.
>
> I'm not totally convinced about the need for a contrib folder in
> trunk. The point of it sounds like so that things can be removed when
> a release is done, but why remove things? I'd rather get feedback from
> users as soon as possible so prefer to include even work in progress
> items in releases.
>
Some reasons for not including these things in a release:
1. They might not be buildable.
2. The developer(s) might know they don't work, in which case getting
feedback saying "feature X doesn't work" wouldn't be very useful.
3. Users might expect that things in a release should work (at least to
some reasonable extent) and they might not be very happy to put time
into trying to use a feature and eventually find that the feature is
incomplete or not ready.
Simon
> ...ant
>
>
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
Posted by ant elder <an...@gmail.com>.
On Thu, Jul 1, 2010 at 8:41 AM, Simon Laws <si...@googlemail.com> wrote:
>> 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.
>
Yes i think thats implied from all the previous discussions we've had
around this, that has to be up to the devs doing the work.
I'm not totally convinced about the need for a contrib folder in
trunk. The point of it sounds like so that things can be removed when
a release is done, but why remove things? I'd rather get feedback from
users as soon as possible so prefer to include even work in progress
items in releases.
...ant
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
Posted by kelvin goodson <ke...@apache.org>.
oops, sorry, will fix
Kelvin.
On Mon, Jul 12, 2010 at 9:37 PM, Raymond Feng <en...@gmail.com> wrote:
> There is probably some misunderstanding as I see the contrib folder is now
> at [1] instead of [2].
> [1] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib
> [2] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/contrib
> If we look back at the thread, we're proposing to have the contrib folder
> under trunk. This way, the stuff under contrib can be part of the main build
> for the trunk.
> Thanks,
> Raymond
> ________________________________________________________________
> Raymond Feng
> rfeng@apache.org
> Apache Tuscany PMC member and committer: tuscany.apache.org
> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
> Personal Web Site: www.enjoyjava.com
> ________________________________________________________________
> On Jul 12, 2010, at 1:27 PM, Luciano Resende wrote:
>
> On Mon, Jul 12, 2010 at 2:04 AM, kelvin goodson
> <ke...@apache.org> wrote:
>
> I created the samples and modules directory under contrib, as I have
>
> need for the samples directory and it's clear from this thread that we
>
> have consensus on needing a samples and a modules directory. I only
>
> found one reference to having the tests folder under contrib, so I
>
> refrained from adding that at the moment, a small point but I thought
>
> I'd just check that's whats wanted before going ahead and doing it.
>
> Kelvin.
>
>
> Could someone please send a link to which contrib folder I should be
> looking for ?
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
>
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet ready for release
Posted by Raymond Feng <en...@gmail.com>.
There is probably some misunderstanding as I see the contrib folder is now at [1] instead of [2].
[1] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib
[2] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/contrib
If we look back at the thread, we're proposing to have the contrib folder under trunk. This way, the stuff under contrib can be part of the main build for the trunk.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Jul 12, 2010, at 1:27 PM, Luciano Resende wrote:
> On Mon, Jul 12, 2010 at 2:04 AM, kelvin goodson
> <ke...@apache.org> wrote:
>> I created the samples and modules directory under contrib, as I have
>> need for the samples directory and it's clear from this thread that we
>> have consensus on needing a samples and a modules directory. I only
>> found one reference to having the tests folder under contrib, so I
>> refrained from adding that at the moment, a small point but I thought
>> I'd just check that's whats wanted before going ahead and doing it.
>>
>> Kelvin.
>>
>
> Could someone please send a link to which contrib folder I should be
> looking for ?
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Jul 12, 2010 at 2:04 AM, kelvin goodson
<ke...@apache.org> wrote:
> I created the samples and modules directory under contrib, as I have
> need for the samples directory and it's clear from this thread that we
> have consensus on needing a samples and a modules directory. I only
> found one reference to having the tests folder under contrib, so I
> refrained from adding that at the moment, a small point but I thought
> I'd just check that's whats wanted before going ahead and doing it.
>
> Kelvin.
>
Could someone please send a link to which contrib folder I should be
looking for ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
Posted by kelvin goodson <ke...@apache.org>.
I created the samples and modules directory under contrib, as I have
need for the samples directory and it's clear from this thread that we
have consensus on needing a samples and a modules directory. I only
found one reference to having the tests folder under contrib, so I
refrained from adding that at the moment, a small point but I thought
I'd just check that's whats wanted before going ahead and doing it.
Kelvin.
On Thu, Jul 1, 2010 at 3:46 PM, Raymond Feng <en...@gmail.com> wrote:
> +1. Good catch for samples and tests.
>
> Sent from my iPhone
>
> On Jul 1, 2010, at 4:10 AM, Simon Nash <na...@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 <en...@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 <si...@googlemail.com> wrote:
>>>>
>>> Simon
>>
>
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet ready for release
Posted by Raymond Feng <en...@gmail.com>.
+1. Good catch for samples and tests.
Sent from my iPhone
On Jul 1, 2010, at 4:10 AM, Simon Nash <na...@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 <en...@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 <si...@googlemail.com> wrote:
>>>
>> Simon
>
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
Posted by kelvin goodson <ke...@apache.org>.
me too
On Thu, Jul 1, 2010 at 3:20 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 6:24 AM, Simon Laws <si...@googlemail.com> wrote:
>> On Thu, Jul 1, 2010 at 12:10 PM, Simon Nash <na...@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
>>
>> Ok by me to have modules and samples as sub-directories of contrib.
>>
>> Simon
>>
>
> All seems good to me.
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Jul 1, 2010 at 6:24 AM, Simon Laws <si...@googlemail.com> wrote:
> On Thu, Jul 1, 2010 at 12:10 PM, Simon Nash <na...@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
>
> Ok by me to have modules and samples as sub-directories of contrib.
>
> Simon
>
All seems good to me.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jul 1, 2010 at 12:10 PM, Simon Nash <na...@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
Ok by me to have modules and samples as sub-directories of contrib.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not
yet ready for release
Posted by Simon Nash <na...@apache.org>.
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 <en...@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 <si...@googlemail.com> wrote:
>>
>
> Simon
>
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet
ready for release
Posted by Simon Laws <si...@googlemail.com>.
Good ideas Raymond. Small comments in-line
On Thu, Jul 1, 2010 at 8:11 AM, Raymond Feng <en...@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 <si...@googlemail.com> wrote:
>
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [DISCUSS] Adding new function to the Tuscany trunk that's not yet ready for release
Posted by Raymond Feng <en...@gmail.com>.
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 :-)
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
b) if the code cannot be built, the module won't be included in the main build
3) Trunk/modules: stable features that are ready for the next release
Developers can adjust things between 2.a and 2.b. We should promote things from 2 into 3 when the features are 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.
Mostly, I prefer to have a "SOFT" separation between the experimental and ready-for-release features.
Sent from my iPhone
On Jun 30, 2010, at 10:47 AM, Simon Laws <si...@googlemail.com> wrote:
> In Tuscany there are no hurdles for getting new code into trunk.
> However it would be easier, come release time, if we knew which
> modules we're ready for release and which where not. Here "ready for
> release" is in the eye of the developer(s) building the module in
> question, i.e. there is no checklist or committee that determines it.
>
> We do have a contrib directory [1] which I think (just my view)
> *currently* fits into the grand scheme of things in the following way:
>
> my sandbox - stuff I just want to work on
> contrib - stuff that I think could go into a release at some point but
> which isn't ready yet
> trunk - stuff which I think is ready to release
>
> I chatted with others about this and there were various opinions about
> how we can improve so starting this [DISCUSS] to see if we can come to
> some common understanding.
>
> [1] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/
>
> Regards
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com