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/[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
--
Jean-Sebastien
