Tom Jordahl wrote:
> I would think that each of the sub projects would have its own set of
> committers. I don't think I should have the rights to muck with the
> WSIF code just because I know what I am doing in Axis.
>
> Given that we expect the number of projects involving web services to
> only increase, I think it would make much more sense that each
> project has its own set of committers, mailing list, CVS tree, etc,
> etc.
>
> I see webservice.apache.org as more of an organizational grouping
> than a 'we are a bunch of people all working on every one of these
> projects'.
>
> I freely admit that there may be Apache organizational principals
> that govern this that I am not aware of....

It is not so much an organizational prinicipal(*) as an evolving awareness of what works and what doesn't work.

Here's an observation to illustrate the point: Axis has grown rather big, hasn't it? Inside Axis is WSDL2Java. I have commit access to this code but Nirmal does not. Why do I have access? I guess the presumption is that if I were to make a change it is likely to be acceptable. If not, a test will likely detect the issue and/or I am likely to support the code I wrote. And failing either of those things, the change can always be backed out.

Does this apply to Nirmal? I would think so, particularly as his code will likely become a customer.

We *could* go down the path where the code is partitioned up very finely with individual access rights to each, but if history is any guide, the likely result is duplication and invention of isolation layers.

What seems to work is if every community is defined as a separate top level Apache project. If WSIF and Axis are separate communities, then lets declare it so and move on. Otherwise, lets declare that and make it so.

- Sam Ruby

(*) Actually Roy Fielding would disagree with me, as he has been consistently advocating the direction we are now heading. Some of us just take a little longer than others to catch on. ;-)



Reply via email to