[all] Making released compontents dormant

[Henri Yandell <fl...@gmail.com>]

Specifically with respect to Latka, but applicable to all Commons components.

How do we want to handle released (ie non-sandboxed) components that
have gone dormant? Do we add a new component called Legacy (or
something like that)?

So:

Released
Legacy
Unreleased
Dormant

Currently we have 6 months as the time to drop out of the unreleased
(sandbox) section and into the dormant section. How long would we want
to be looking at to start a vote to drop things from Released into
Legacy? 1 year? 2 years?

Hen

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

Re: [all] Making released compontents dormant

[Phil Steitz <ph...@gmail.com>]

On 2/12/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> On Tue, 2006-02-07 at 12:37 -0500, Rahul Akolkar wrote:
> > On 2/7/06, Henri Yandell <fl...@gmail.com> wrote:
> > > Specifically with respect to Latka, but applicable to all Commons components.
> > <snip/>
> >
> > Thanks for bringing this up, its been something I (and possibly
> > others) have been wondering as well.
> >
> > Add EL to that starting list.
>
> EL is actually an interesting example...
>
> > > How do we want to handle released (ie non-sandboxed) components that
> > > have gone dormant? Do we add a new component called Legacy (or
> > > something like that)?
> > >
> > <snap/>
> >
> > Ofcourse we do. As Robert points out there may be separate "legacy"
> > and "matured beyond belief" categories (even though the second
> > category has extremely limited membership, IMO), but the undercurrent
> > still holds -- some components are not supported as well as we'd hope
> > (I just browsed the archives for unanswered questions, and bugzilla
> > for unanswered tickets).
>
> legacy would be a very misleading term for EL. EL is definitely
> finished.
>
> i wonder whether there's something like a main sequence for components:
>
> sandbox -> immature (aka unreleased) -> stable -> mature -> finished
>
> and whether we could make use of it...

Have to allow for loops.  Some things go dormant for a while and then
"wake up" again.  I am not sure what problem we are trying to solve
here.  If it is making it clear what components are not being actively
supported, I am +1, if it is declaring things "finished" I see no
point in that, and potentially some loss in doing it (discourages
contributions to "finished" components).

Phil

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

Re: [all] Making released compontents dormant

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Tue, 2006-02-07 at 12:37 -0500, Rahul Akolkar wrote:
> On 2/7/06, Henri Yandell <fl...@gmail.com> wrote:
> > Specifically with respect to Latka, but applicable to all Commons components.
> <snip/>
> 
> Thanks for bringing this up, its been something I (and possibly
> others) have been wondering as well.
> 
> Add EL to that starting list.

EL is actually an interesting example...

> > How do we want to handle released (ie non-sandboxed) components that
> > have gone dormant? Do we add a new component called Legacy (or
> > something like that)?
> >
> <snap/>
> 
> Ofcourse we do. As Robert points out there may be separate "legacy"
> and "matured beyond belief" categories (even though the second
> category has extremely limited membership, IMO), but the undercurrent
> still holds -- some components are not supported as well as we'd hope
> (I just browsed the archives for unanswered questions, and bugzilla
> for unanswered tickets).

legacy would be a very misleading term for EL. EL is definitely
finished.

i wonder whether there's something like a main sequence for components:

sandbox -> immature (aka unreleased) -> stable -> mature -> finished

and whether we could make use of it...

- robert


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

Re: [all] Making released compontents dormant

[Rahul Akolkar <ra...@gmail.com>]

On 2/7/06, Henri Yandell <fl...@gmail.com> wrote:
> Specifically with respect to Latka, but applicable to all Commons components.
<snip/>

Thanks for bringing this up, its been something I (and possibly
others) have been wondering as well.

Add EL to that starting list.


>
> How do we want to handle released (ie non-sandboxed) components that
> have gone dormant? Do we add a new component called Legacy (or
> something like that)?
>
<snap/>

Ofcourse we do. As Robert points out there may be separate "legacy"
and "matured beyond belief" categories (even though the second
category has extremely limited membership, IMO), but the undercurrent
still holds -- some components are not supported as well as we'd hope
(I just browsed the archives for unanswered questions, and bugzilla
for unanswered tickets).


> So:
>
> Released
> Legacy
> Unreleased
<snip/>

IMO, Sandbox has too much "history" (going back to our charter) to
change its name ATM (not sure if you were implying that, probably
not).


> Dormant
>
> Currently we have 6 months as the time to drop out of the unreleased
> (sandbox) section and into the dormant section. How long would we want
> to be looking at to start a vote to drop things from Released into
> Legacy? 1 year? 2 years?
>
<snap/>

It'd be fine to err on the conservative side for components in proper
(released), I believe 1 year is conservative enough. Ofcourse, this
has to do with more than svn check ins (email traffic & the general
"feel" as mvdb puts it) but I believe all this is doable (with votes)
and should be done. We have adequate standards for sandbox components
in place now, IMO, its time we followed up on a similar note with the
released components as well.

-Rahul


> Hen
>

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

Re: [all] Making released compontents dormant

[Martin van den Bemt <ml...@mvdb.net>]

Don't think a time limit will do the trick here. It is just if everyone thinks or feels the 
component is dormant*. You mention in your reply to Robert that it will be based on commits, which 
is also not the way to go (although can be an indicator, depending on the number of commits). When I 
find a bug message about documentation I will try to fix that, which already means a commit, but by 
no way means the component is active again.

A good way to find dormant components is to have a look at bugzilla. We have a shitload of issues 
there that probably never will be resolved. I have this on my todo list to propose something to make 
that more managaeble (ehh just set to closed or resolved won't fix) very old issues, at least those 
without any comments from committers (latka comes to mind, issues from 2003 are still open there). 
Other issues which are old and assigned, I will try to ping the assignee.
In some cases, I could even start applying patches where there are complete patches provided (with 
tests, etc), to give the community a chance to drive development of those dormant components, with 
of course some oversight.

In short : it would be nice to see a cleanup of bugzilla (probably better start a seperate VOTE 
about this). People can always reopen an issue if they are still interested to see something fixed 
after more than eg a year waiting to get their problem solved.

*) dormant in this mail doesn't specifically mean the svn dormant.

Mvgr,
Martin



Henri Yandell wrote:
> Specifically with respect to Latka, but applicable to all Commons components.
> 
> How do we want to handle released (ie non-sandboxed) components that
> have gone dormant? Do we add a new component called Legacy (or
> something like that)?
> 
> So:
> 
> Released
> Legacy
> Unreleased
> Dormant
> 
> Currently we have 6 months as the time to drop out of the unreleased
> (sandbox) section and into the dormant section. How long would we want
> to be looking at to start a vote to drop things from Released into
> Legacy? 1 year? 2 years?
> 
> Hen
> 
> ---------------------------------------------------------------------
> 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

Re: [all] Making released compontents dormant

[Henri Yandell <fl...@gmail.com>]

On 2/7/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> On Tue, 2006-02-07 at 09:44 -0500, Henri Yandell wrote:
> > Specifically with respect to Latka, but applicable to all Commons components.
> >
> > How do we want to handle released (ie non-sandboxed) components that
> > have gone dormant? Do we add a new component called Legacy (or
> > something like that)?
> >
> > So:
> >
> > Released
> > Legacy
> > Unreleased
> > Dormant
> >
> > Currently we have 6 months as the time to drop out of the unreleased
> > (sandbox) section and into the dormant section. How long would we want
> > to be looking at to start a vote to drop things from Released into
> > Legacy? 1 year? 2 years?
>
> i'm not sure that legacy is really the right word here. legacy implies
> that there it's not supported whereas the case may be that a component
> is just finished. it should be expected that the quantity of coding on
> the components we have here should gradually move towards zero: in the
> end, bugs get fixed and code factored out into newer more specialist
> components.
>
> a good example would be collections. this is a great library but active
> development is now approaching zero. labelling collections as legacy
> would mislead users into thinking that they should not use this library
> whereas the message should be that this library is so well tested and
> widely used that bugs are very few and so feature-filled that worthy
> extensions are now rare.

+1. I'm aiming for the not supported with the legacy term. Inactivity
is just a way to start a vote.

So in this case, someone would nominate Collections for legacy, and
someone else would say that they are actively monitoring it. Maybe
they would commit to a file in it (the README or something). In a
years time, it would come up again.

> i'm also worried that we're failing to distinguish between different
> states: libraries (if they are sufficiently popular) will evolve to a
> stage whereby development slows since they are just about finished. IMHO
> lumping these together with libraries which are not finished but which
> no longer have an active development community will just confuse
> developers and users.

+1. Quite likely that Latka should actually be demoted to the Sandbox
and then put into Dormant, rather than becoming Legacy. BeanUtils on
the other hand could goto Legacy (assuming no one is maintaining it).
Also +1 to a better word than Legacy.

How do we define maintain too. DbUtils needs a release; if a user asks
for a release and we're unable to release, that definitely strikes me
as legacy. A component on which our committer community is not
currently responding.

Then again, ECS, Regexp, ORO all are examples of Jakarta components
that have a single committer watching them. Ideally the
released-dormant concept we come up with would be applicable there. I
bet all three get user questions generally answered, and could have
releases if need be, but they also seem to be in the released-dormant
zone.

Hen

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

Re: [all] Making released compontents dormant

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Tue, 2006-02-07 at 09:44 -0500, Henri Yandell wrote:
> Specifically with respect to Latka, but applicable to all Commons components.
> 
> How do we want to handle released (ie non-sandboxed) components that
> have gone dormant? Do we add a new component called Legacy (or
> something like that)?
> 
> So:
> 
> Released
> Legacy
> Unreleased
> Dormant
> 
> Currently we have 6 months as the time to drop out of the unreleased
> (sandbox) section and into the dormant section. How long would we want
> to be looking at to start a vote to drop things from Released into
> Legacy? 1 year? 2 years?

i'm not sure that legacy is really the right word here. legacy implies
that there it's not supported whereas the case may be that a component
is just finished. it should be expected that the quantity of coding on
the components we have here should gradually move towards zero: in the
end, bugs get fixed and code factored out into newer more specialist
components. 

a good example would be collections. this is a great library but active
development is now approaching zero. labelling collections as legacy
would mislead users into thinking that they should not use this library
whereas the message should be that this library is so well tested and
widely used that bugs are very few and so feature-filled that worthy
extensions are now rare. 

i'm also worried that we're failing to distinguish between different
states: libraries (if they are sufficiently popular) will evolve to a
stage whereby development slows since they are just about finished. IMHO
lumping these together with libraries which are not finished but which
no longer have an active development community will just confuse
developers and users.

- robert


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