jakarta-oro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@apache.org>
Subject Re: jakarta-oro dilemma
Date Wed, 13 Aug 2003 05:28:10 GMT
On Tue, 12 Aug 2003, Daniel F. Savarese wrote:

> There are several, not necessarily mutually exclusive, possibilities:
>   1. PMC evaluates situation and votes in two committers, restoring the
>      necessary quorum.

If they have 2 votes already ( you and Jon ), I think they deserve a third 

>   2. PMC takes over voting responsibility for releases, which I believe
>      is the long term goal for all Jakarta projects.  In this case, I'd
>      request to be added to/voted onto the PMC because I'm a former PMC
>      member and someone from the project should be around to initiate
>      votes.

+1 on adding you (back) to the PMC ( I don't know if a vote is necesary or 
it's automatic). 

AFAIK PMC has reponsibility for releases - but in most cases the vote to 
release is done by people involved, so you still need 3 people who are 
involved in the project.

>   3. Project is opened up to all Jakarta committers and those interested
>      subscribe to dev mailing list and participate in votes.

+1 ( my favorite option :-)

>   4. Make jakarta-regexp committers jakarta-oro committers and vice versa,
>      as I believe jakarta-regexp is in a similar situation to jakarta-oro.
>      Whether or not the two projects would merge would be decided later,
>      but participants of each could take an active role in helping the
>      other project along.

+1 too, this is a subset of (3). 

>   5. A call for participation is made to general@jakarta and any already
>      existing Jakarta committer willing to contribute some time to the
>      project is automatically made a committer for the project.

I preffer 3.

> I'm sure there are additional alternatives.  I'm happy with any of the
> above.
> Specifically, we've been wanting to vote on
> Takashi Okamoto <tokamoto at rd.nttdata.co.jp> and
> Mark Murphy <markm at tyrell.com>
> as committers, because of the significant code contributions they
> have made and their continued active participation in development
> discussions.
> As a side note, the project has been hindered by its advanced
> stage of development when initially imported as a Jakarta project
> (no itches to scratch), initial reluctance to vote in committers
> because of SVN always being on the horizon and my (mis)perception that
> the ASF wanted to limit the creation of new committer accounts, and more
> recently, the J2SE 1.4 javax.regex package.  However, there is still a
> role for jakarta-oro to play in the Java and Jakarta ecosystems, but we
> have to break the project out of it's current doldrums.  The problems
> that developed with jakarta-oro did not arise with commons-net because
> I took a back seat and forced the user community to take the lead and
> become the development community before it entered the commons-sandbox
> and then commons proper.  In other words, commons-net is healthy and
> will survive without my participation, but I'm afraid the same isn't
> the case with jakarta-oro and we need to get it to that point.  As I
> mentioned above, jakarta-regexp is also in a paralyzed state, with only
> one truly active committer, preventing release votes.  So in considering
> jakarta-oro, jakarta-regexp should also be considered.

I think merging jakarta-oro and jakarta-regexp and opening them up to 
the entire jakarta ( like commons or gump ) would be the best solution.

AFAIK there are still a lot of projects with JDK1.2 or JDK1.3 as minimal
platform, and ORO has more features than 1.4. It is true that a feature 
bundled into JDK may negatively impact standalone components, but features
in J2SE have a very long release cycle ( dependent on JDK releases ), 
little room to evolve and fewer contributors. In addition each new JDK 
feature is adding complexity to all projects that need to support older
JDKs, etc. 

IMO the biggest problem with jakarta-oro and jakarta-regexp is the lack
of a common API. I suppose it wouldn't be easy ( or possible ) to 
implement the APIs in JDK1.4 - or to use a common API for both.


View raw message