Sam Ruby wrote:
Andy Clark wrote:
So I say make every project independent (unless
there is a direct, mandatory dependency -- i.e. a
sub-project) and then allow each project to decide
which taxonomy (or taxonomies) that are appropriate.
Is that something you plan to mandate and enforce? If so, how?
I'm not talking about mandating anything. It's just
that each project could make its own decision about
"where" they live (i.e. what category or categories).
So if a project crosses boundaries, that's perfectly
acceptable.
Should what was once Apache Jakarta Avalon Excalibur Threadcontext be a
separate project, or is it sufficient for Avalon to be a separate
project (as it is now)?
In my scheme, Jakarta is just another category and
it can contain any number of projects or sub-projects.
Whether a codebase (and its developer community) is
a full-fledged project or a direct sub-project would
be decided by the projects in question.
Ted is questioning whether or not the XML PMC is providing sufficient
oversight. It is a valid question.
As a developer in the XML project, we hardly ever
saw anything that the PMC did. They weren't there to
provide a "vision" or "guidance"; they took care of
the legalities, etc. Which is fine. The vision for
each project should come from the people directly
contributing to the codebase. But there was a
disconnect between the developers and the PMC
because none of the day to day developers were on
the PMC (after Ted moved on).
But I ramble...
In short, I think the XML PMC was doing some work
but it didn't *feel* like enough oversight. Putting
developers involved with the codebase on the PMC
would go a long way towards correcting this.
example: should Xerces and Xalan have a unified set of committers or
should these lists be separate? This is a question that can be resolved
in bottom up manner.
I imagine that most Xerces developers don't want to
work on Xalan and most Xalan developers don't want to
work on Xerces. Xalan depends on Xerces but they are
definitely separate communities. There are some areas,
though, where overlap will occur (e.g. serializers)
so we'll need to work that out.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
