----- Original Message -----
From: "Elena Litani" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 28, 2002 9:47 AM
Subject: Sub-projects [was: [Proposal] jing integrated in to Xerces?]


> I am OK with the idea of *adopting* Neko and Jing, however, I would like
> to see those as sub-projects.
>
> As Arnaud mentioned, we've previously discussed the idea of creating a
> sub-project of NekoHTML, however, the discussion stopped without any
> outcome. I suggest we refresh our memory on the past suggestions and
> finally decide what and how many sub-projects we create, including the
> details on how we manage those.
>
> Here is the list of proposals (the ones made in the past and new ones):
>
> 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?

I think the criteria should be interest amongst committers or potential
committers.
If there are a few committers (my preference at least 2, 3 is best) who are
willing to
work on the sub project, that should be easy, unless another committer wants
to vote -1.
However, I also think that subprojects are a great way to provide an entry
point for
new committers.  So I'd also be in favor if a proposed subproject had one
committer
and a few non-committers who had a serious interest in working on the
subproject -
especially with an eye towards giving the new folks commit privileges.

> 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.

+1 on 2b.

> 3. Do we want to create only one sub-project, i.e. "toolbox"?

Is the goal here to reduce sub-project proliferation, to give sub-projects
a place to grow up, or some other goal?

> 4. Sub-projects should have its own build file, documentation and jar
> files, i.e. xerces-neko.jar.

+1

> 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.

+1 on 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.

+1 on c.  If a subproject got really big (lots of traffic etc) then we
should
start a new mailing list.  But as each sub-project starts up, they should
initially
be a part of Xerces.

> 7. Sub-projects should have its own releases (which don't necessarily
> match Xerces ones).

+1

> 8. We should consider separate HTML/WML DOM components from the main
> Xerces projects.

+1

>
> Thank you,

Thanks for making this concrete...

> --
> Elena Litani / IBM Toronto
>
> ---------------------------------------------------------------------
> 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]

Reply via email to