You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Daniel F. Savarese" <df...@savarese.org> on 2007/04/04 21:51:36 UTC

Re: [all] Going TLP?

+1 on the TLP vote

In message <F0...@esmail.elsag.de>, =?iso-88
59-1?Q?J=F6rg_Schaible?= writes:
>I never got why things like ECS, ORO, regexp are not part of commons. =
>What makes them different to logging or digester? I can understand the =
>separation for something like POI, but not necessarily for components I =
>would describe as utitlity libs. Maybe I'm lacking simply historical =
>reasons though ...

For at least ORO, there has been no opposition to moving it into Commons
that I can recall.  It hasn't happened because folks have taken the
initiative only to propose it, not to actually do it.  There's also
been the issue that being forced to rename the the packages to
org.apache.commons.oro, org.apache.commons.regexp, etc. breaks lots of
existing code.  However, "done" projects like ORO and regexp are being
viewed as unwanted baggage by some folks despite the value they've
provided for many years, so I don't know if they'll be allowed to follow
commons.  They don't belong in Dormant because they have actual releases,
but they don't belong in Proper because they are primarily consumed, not
developed (albeit they are maintained).  The options advocated at Jakarta
are always dead or alive for some reason and don't allow for finished.
If the Commons community does not oppose allowing for projects to
become finished/complete, then some of these can and probably should
follow (e.g., the 1.4 branch of Commons Net relies on ORO).  But I
would suggest any further discussion of this be postponed until after
the move of Commons to a TLP.  If each issue is handled separately,
some progress may actually be made.

daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [all] Going TLP?

Posted by Henri Yandell <fl...@gmail.com>.
+1 to everything in your email. There's lots of room for 'finished' or
'maintenance' as it seems to be called more often. We've already got
that in Commons in Discovery and Attributes at the very least.

Hen

On 4/4/07, Daniel F. Savarese <df...@savarese.org> wrote:

> For at least ORO, there has been no opposition to moving it into Commons
> that I can recall.  It hasn't happened because folks have taken the
> initiative only to propose it, not to actually do it.  There's also
> been the issue that being forced to rename the the packages to
> org.apache.commons.oro, org.apache.commons.regexp, etc. breaks lots of
> existing code.  However, "done" projects like ORO and regexp are being
> viewed as unwanted baggage by some folks despite the value they've
> provided for many years, so I don't know if they'll be allowed to follow
> commons.  They don't belong in Dormant because they have actual releases,
> but they don't belong in Proper because they are primarily consumed, not
> developed (albeit they are maintained).  The options advocated at Jakarta
> are always dead or alive for some reason and don't allow for finished.
> If the Commons community does not oppose allowing for projects to
> become finished/complete, then some of these can and probably should
> follow (e.g., the 1.4 branch of Commons Net relies on ORO).  But I
> would suggest any further discussion of this be postponed until after
> the move of Commons to a TLP.  If each issue is handled separately,
> some progress may actually be made.
>
> daniel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org