Sounds fine to me, +1.

On 3/21/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> 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/[EMAIL 
> PROTECTED]
> ,
>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/[EMAIL 
> PROTECTED]
> ,
> and
>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/[EMAIL 
> PROTECTED]
> 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
>
>

Reply via email to