You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2006/03/22 00:02:37 UTC
Rules of engagement for binding and container contributions
A number of recent emails raised some questions on how we should handle
new binding and container type contributions (e.g container.js,
binding.jsonrpc). See
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c71e1b5740603161147q38517447h8c4bfcc467bb0269@mail.gmail.com%3e,
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c441FBF30.3090607@apache.org%3e,
and
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c2DD2BF40-B7B7-4875-A72A-A5085E8A0815@gmail.com%3e
for the discussion threads.
I'd like to propose some simple rules to handle these cases, with two
goals in mind:
- minimize the pain caused by build breaks
- provide a dynamic environment making it as easy as possible for the
community to contribute new binding and container extensions
1. We should give a heads up on new binding/container contributions on
the dev list, to make all the people in the group aware of what's going
on and not catch anybody by surprise.
2. All contributions should be part of the main build (unless they drag
unreasonable dependencies).
3. When a contribution breaks the build (potentially caused by a change
in the core runtime), JIRA issues need to be opened, people work
together to get it fixed.
4. if it takes too long or the people who can fix it are not available
or in a position to help then we should have a vote to temporarily
remove the particular contribution from the build.
Any thoughts?
--
Jean-Sebastien
Re: Rules of engagement for binding and container contributions
Posted by Jim Marino <ji...@gmail.com>.
O.K. then I think this covers my concerns around extension checkins
to main.
Jim
On Mar 21, 2006, at 6:26 PM, Jean-Sebastien Delfino wrote:
> Jim Marino wrote:
>
>> In general I like this approach. I believe it is important to
>> communicate these types of changes on the list, particularly
>> because it is a low overhead thing to do.
>>
>> The threads pointed to also raise an additional issue that is
>> somewhat related but perhaps separate around project structuring.
>> Jeremy proposed a project structuring which makes sense to me (it
>> may need to be modified somewhat but as a starting point it seems
>> to work). In #2 below, are you proposing a flat project structure
>> or just not addressing that issue here? For example, making
>> "contributions part of the main build" could be interpreted as
>> meaning a flat structure, one similar to Jeremy's, or something
>> entirely different. I'm happy to say we say address that in a
>> separate discussion so we can reach consensus on this issue first.
>>
>>
> Yes, let's focus this thread on the rules of engagements, I've
> already expressed my opinion on the project structure in the
> "Project Structure" thread.
>
>
>> Jim
>>
>>
>> On Mar 21, 2006, at 3:02 PM, Jean-Sebastien Delfino wrote:
>>
>>
>>> A number of recent emails raised some questions on how we should
>>> handle new binding and container type contributions (e.g
>>> container.js, binding.jsonrpc). See http://mail-
>>> archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%
>>> 3c71e1b5740603161147q38517447h8c4bfcc467bb0269@mail.gmail.com%3e,
>>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/
>>> 200603.mbox/%3c441FBF30.3090607@apache.org%3e, and
>>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/
>>> 200603.mbox/%3c2DD2BF40-B7B7-4875-A72A-A5085E8A0815@gmail.com%3e
>>> for the discussion threads.
>>>
>>> I'd like to propose some simple rules to handle these cases, with
>>> two goals in mind:
>>> - minimize the pain caused by build breaks
>>> - provide a dynamic environment making it as easy as possible for
>>> the community to contribute new binding and container extensions
>>>
>>> 1. We should give a heads up on new binding/container
>>> contributions on the dev list, to make all the people in the
>>> group aware of what's going on and not catch anybody by surprise.
>>> 2. All contributions should be part of the main build (unless
>>> they drag unreasonable dependencies).
>>> 3. When a contribution breaks the build (potentially caused by a
>>> change in the core runtime), JIRA issues need to be opened,
>>> people work together to get it fixed.
>>> 4. if it takes too long or the people who can fix it are not
>>> available or in a position to help then we should have a vote to
>>> temporarily remove the particular contribution from the build.
>>>
>>> Any thoughts?
>>>
>>> --Jean-Sebastien
>>>
>>>
>>>
>>
>>
>>
> --
> Jean-Sebastien
>
>
Re: Rules of engagement for binding and container contributions
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jim Marino wrote:
> In general I like this approach. I believe it is important to
> communicate these types of changes on the list, particularly because
> it is a low overhead thing to do.
>
> The threads pointed to also raise an additional issue that is somewhat
> related but perhaps separate around project structuring. Jeremy
> proposed a project structuring which makes sense to me (it may need to
> be modified somewhat but as a starting point it seems to work). In #2
> below, are you proposing a flat project structure or just not
> addressing that issue here? For example, making "contributions part of
> the main build" could be interpreted as meaning a flat structure, one
> similar to Jeremy's, or something entirely different. I'm happy to say
> we say address that in a separate discussion so we can reach consensus
> on this issue first.
>
Yes, let's focus this thread on the rules of engagements, I've already
expressed my opinion on the project structure in the "Project Structure"
thread.
> Jim
>
>
> On Mar 21, 2006, at 3:02 PM, Jean-Sebastien Delfino wrote:
>
>> A number of recent emails raised some questions on how we should
>> handle new binding and container type contributions (e.g
>> container.js, binding.jsonrpc). See
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c71e1b5740603161147q38517447h8c4bfcc467bb0269@mail.gmail.com%3e,
>>
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c441FBF30.3090607@apache.org%3e,
>> and
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c2DD2BF40-B7B7-4875-A72A-A5085E8A0815@gmail.com%3e
>> for the discussion threads.
>>
>> I'd like to propose some simple rules to handle these cases, with two
>> goals in mind:
>> - minimize the pain caused by build breaks
>> - provide a dynamic environment making it as easy as possible for the
>> community to contribute new binding and container extensions
>>
>> 1. We should give a heads up on new binding/container contributions
>> on the dev list, to make all the people in the group aware of what's
>> going on and not catch anybody by surprise.
>> 2. All contributions should be part of the main build (unless they
>> drag unreasonable dependencies).
>> 3. When a contribution breaks the build (potentially caused by a
>> change in the core runtime), JIRA issues need to be opened, people
>> work together to get it fixed.
>> 4. if it takes too long or the people who can fix it are not
>> available or in a position to help then we should have a vote to
>> temporarily remove the particular contribution from the build.
>>
>> Any thoughts?
>>
>> --Jean-Sebastien
>>
>>
>
>
--
Jean-Sebastien
Re: Rules of engagement for binding and container contributions
Posted by Jim Marino <ji...@gmail.com>.
In general I like this approach. I believe it is important to
communicate these types of changes on the list, particularly because
it is a low overhead thing to do.
The threads pointed to also raise an additional issue that is
somewhat related but perhaps separate around project structuring.
Jeremy proposed a project structuring which makes sense to me (it may
need to be modified somewhat but as a starting point it seems to
work). In #2 below, are you proposing a flat project structure or
just not addressing that issue here? For example, making
"contributions part of the main build" could be interpreted as
meaning a flat structure, one similar to Jeremy's, or something
entirely different. I'm happy to say we say address that in a
separate discussion so we can reach consensus on this issue first.
Jim
On Mar 21, 2006, at 3:02 PM, Jean-Sebastien Delfino wrote:
> A number of recent emails raised some questions on how we should
> handle new binding and container type contributions (e.g
> container.js, binding.jsonrpc). See http://mail-archives.apache.org/
> mod_mbox/ws-tuscany-dev/200603.mbox/%
> 3c71e1b5740603161147q38517447h8c4bfcc467bb0269@mail.gmail.com%3e,
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/
> %3c441FBF30.3090607@apache.org%3e, and
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/
> %3c2DD2BF40-B7B7-4875-A72A-A5085E8A0815@gmail.com%3e for the
> discussion threads.
>
> I'd like to propose some simple rules to handle these cases, with
> two goals in mind:
> - minimize the pain caused by build breaks
> - provide a dynamic environment making it as easy as possible for
> the community to contribute new binding and container extensions
>
> 1. We should give a heads up on new binding/container contributions
> on the dev list, to make all the people in the group aware of
> what's going on and not catch anybody by surprise.
> 2. All contributions should be part of the main build (unless they
> drag unreasonable dependencies).
> 3. When a contribution breaks the build (potentially caused by a
> change in the core runtime), JIRA issues need to be opened, people
> work together to get it fixed.
> 4. if it takes too long or the people who can fix it are not
> available or in a position to help then we should have a vote to
> temporarily remove the particular contribution from the build.
>
> Any thoughts?
>
> --
> Jean-Sebastien
>
>
Re: Rules of engagement for binding and container contributions
Posted by ant elder <an...@gmail.com>.
Sounds fine to me, +1.
On 3/21/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> A number of recent emails raised some questions on how we should handle
> new binding and container type contributions (e.g container.js,
> binding.jsonrpc). See
>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c71e1b5740603161147q38517447h8c4bfcc467bb0269@mail.gmail.com%3e
> ,
>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c441FBF30.3090607@apache.org%3e
> ,
> and
>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c2DD2BF40-B7B7-4875-A72A-A5085E8A0815@gmail.com%3e
> for the discussion threads.
>
> I'd like to propose some simple rules to handle these cases, with two
> goals in mind:
> - minimize the pain caused by build breaks
> - provide a dynamic environment making it as easy as possible for the
> community to contribute new binding and container extensions
>
> 1. We should give a heads up on new binding/container contributions on
> the dev list, to make all the people in the group aware of what's going
> on and not catch anybody by surprise.
> 2. All contributions should be part of the main build (unless they drag
> unreasonable dependencies).
> 3. When a contribution breaks the build (potentially caused by a change
> in the core runtime), JIRA issues need to be opened, people work
> together to get it fixed.
> 4. if it takes too long or the people who can fix it are not available
> or in a position to help then we should have a vote to temporarily
> remove the particular contribution from the build.
>
> Any thoughts?
>
> --
> Jean-Sebastien
>
>