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