Hi folks,
After a bit of thought, here's a bit more feedback on these questions:
I think it would be tempting fate to offer, as a matter of policy, to
accept code so long as it comes with a single contributor, whatever the
level of user interest. It seems to me that each code contribution should
be judged on a case-by-case basis: Andy's been in this community longer
than almost anyone, so it's fine to include a project that he's the only
one who's worked on; we can be pretty sure Andy will keep maintaining it.
The same may not be true in other cases.
The bottom line for me is that, unless we've known the person for a long
time, I'd like to see at least two folks, with clear familiarity with and
commitment to the donated code, before we decided to accept it.
As to organization: I think I'd prefer to see separate CVS repositories.
This would make divorcing Xerces from unmaintained subprojects a good deal
easier, and would also leave a far clearer trail of responsibility for
problems in the subprojects. Obviously, by accepting these donations, the
Xerces community is accepting some responsibility for their meintenance;
but maintaining Xerces itself is work enough, so the effort Xerces-focused
committers will be able to devote to resuscitating dead subprojects is
going to be *very* limited.
If we can't for whatever reason do separate repositories, then, as we
contemplate sub-projectizing, prrhaps we should also think about drafting
some formal policy on decommissioning subprojects. The WML DOM is an
obbvious candidate: there's no evidence anyone to speak of uses it, and it
sure isn't being maintained... It would be too bad if anyone started
relying on it, believing that its Apache affiliation meant it was solid,
living code.
My only other thought is a detail: With serialization having made its way
into DOM level 3's LS spec, and since we've committed at various times to
supporting it as soon as its a Rec/is permitted by the appropriate TCK, we
probably don't want to sub-projectize that code. My own preference,
actually, would be to see us and Xalan converge on a common serializer;
theirs represents a fork of the code we have, and it wouldn't be all that
hard--if we could agree on a common package name--to make this into one
codebase. In the long term, that'd save everybody maintenance work and
would likely mean optimally robust code for our users...
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+---------------------------->
| | Andy Clark |
| | <[EMAIL PROTECTED]|
| | > |
| | |
| | 11/29/2002 10:12 |
| | PM |
| | Please respond to|
| | xerces-j-dev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Sub-projects [was: [Proposal] jing integrated in to Xerces?]
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
Elena Litani wrote:
> I am OK with the idea of *adopting* Neko and Jing, however, I would like
> to see those as sub-projects.
Agreed. And we should break out the HTML DOM, the
WML DOM, and the serialization code at the same
time.
> 1. What is the criteria for creating a sub-project? Should we consider
> how many committers are interested and willing to work on the
> sub-project, should we consider user requirements? Where does the vote
> take place, i.e. xerces-j-dev, xerces-j-user?
For some protential sub-projects (e.g. NekoHTML),
there aren't more than a single developer. But
there is enough interest from the Xerces user
community to warrant its inclusion. So as long
as code comes with a single contributor, I think
that's okay. We just don't want code to be
orphaned.
We could use the xerces-j-user list to gauge the
interest in proposed sub-projects. But I would have
the final vote happen on xerces-j-dev.
> 2. Sub-project repositories:
> a) Have separate repositories.
> b) Add sub-projects under "xml-xerces/java", i.e.
> "xml-xerces/java/neko", "xml-xerces/java/relaxng".
> I have a slight preference for this approach.
2b.
But I wouldn't put each sub-project into its own
directory directly from xml-xerces/java/. Over time,
that will get very cluttered. I would suggest a top
level dir for the sub-projects. Any suggestions?
> 3. Do we want to create only one sub-project, i.e. "toolbox"?
If we took this approach, we might as well just put
the code in the main src/ dir and have different
build scripts.
> 4. Sub-projects should have its own build file, documentation and jar
> files, i.e. xerces-neko.jar.
Agreed, except for the Jar file name example. I'd
prefer to not load up two codenames into a single
filename -- very confusing. The name should indicate
the function (e.g. xercesHtml.jar).
> 5. Exposing sub projects:
> a) sub-projects could be linked directly from the xml.apache.org web
> site
> b) sub-projects are linked from the Xerces web site.
5b.
> 6. Mailing lists:
> a) Create a mailing list for developers/users of the sub-project.
> b) Create one mailing list for all sub-projects.
> c) Don't create any mailing lists -- use xerces-j-dev/user for
> discussions.
6c.
> 7. Sub-projects should have its own releases (which don't necessarily
> match Xerces ones).
Agreed. But they will need to be documented as to
which Xerces release they depend on much like the
way Xalan depends on a specific release. Trying to
make sure that all sub-projects are up-to-speed
before each Xerces release would be difficult.
> 8. We should consider separate HTML/WML DOM components from the main
> Xerces projects.
Yes. When we add in NekoHTML, the HTML DOM could
be combined with that. Speaking of which, do we
have anyone that wants to update the HTML DOM
implementation for XHTML?
And while I'm thinking about it... We should do
some much needed performance work on the HTML DOM
implementation. I've heard from users of NekoHTML
that the HTML DOM impl consumes a lot of the
overall cycles.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
