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/%
[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
