----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 02, 2002 3:18 PM Subject: Re: Sub-projects [was: [Proposal] jing integrated in to Xerces?]
> 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. I'd prefer to have at least one existing committer who will be like a sponsor for any new subprojects. I wasn't really imagining lots of Xerces subprojects, either. I agree that we can do this on a case by case basis. > 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. I think that we can give a reasonable amount of warning -- say a few releases worth and then deprecate / decommission the subproject code. If during the warning period people want to step up and help, then problem solved. If not, the code goes away. > 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... A common serializer is definitely a good idea. Ted > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
