commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [ALL] Commons Attic
Date Mon, 11 Apr 2011 15:10:52 GMT
This is all true, but I would suspect that while components in "proper" are likely to follow
this pattern, those in "dormant" have a high probability of staying that way, although there
are some good ideas there.

Ralph

On Apr 11, 2011, at 7:58 AM, Phil Steitz wrote:

> On 4/11/11 5:46 AM, Stephen Colebourne wrote:
>> My preference would be a standard labelling across commons (and later
>> perhaps other projects).
>> 
>> This is a lot easier to do than moving projects about in a VCS,
>> changing JIRA, mailing lists etc. Plus it doesn't break any URLs.
>> 
>> Simply have a label (ie. an icon like the CC icons) that summarises
>> the status - "Active", "Stable", "Deprecated". This feels a lot easier
>> for users to manage, and still sends out a signal.
>> 
>> Plus, a binary choice betwen active and dead is too harsh for my taste.
> 
> Thinking about it more, I tend to agree with Stephen on the "making
> it easier" part but I am not sure I agree that any but the most
> coarse-grained labeling is a good idea.  The thing about Commons is
> that components do go effectively "quiet" for relatively long
> periods and then something happens to wake them up again.  The
> "waking up again" part should be as easy and natural as possible. 
> When you think about it, we have very few components that are
> "continuously active," (e.g. [math], [lang]) a decent clump that get
> activity sporadically once in a while ([beanutils], [dbutils],
> [codec], [io]), [configuration], some that look like they have gone
> dormant but then wake up when someone gets a motivating itch around
> them  ([daemon], [vfs], [JXPath]) and then some that seem to be
> completely dead ([primitives], [attributes], [jelly]?, [chain]?...).
> 
> An example I keep thinking about is [chain].  Simple, stable,
> arguably "finished" component.  But we have had some interesting
> suggestions for extension, just not quite enough community or
> committer energy to get them moving.  Would we get those requests if
> we "called it like it is" and put [chain] into the attic or labeled
> it "dead?"  Almost certainly not.  Would we make it less likely that
> energy would build to the point where something interesting would
> happen if we did this?  Almost certainly yes.  Questions about
> [chain] do get responses here and on the dev list, so for all
> practical purposes is is "alive."  What exactly are we expecting to
> communicate to users when we "label" components?  If you think
> carefully about this, what we end up doing is characterizing
> ourselves rather than the components.
> 
> Phil
>> Stephen
>> 
>> 
>> On 11 April 2011 06:12, Henri Yandell <flamefew@gmail.com> wrote:
>>> Currently we have 3 areas in which components live:
>>> 
>>> * Proper: Released components.
>>> * Sandbox: Active pre-release components.
>>> * Dormant: Inactive pre-release components.
>>> 
>>> There's an obvious (to me) need for Proper to split into active and
>>> inactive. Given the existing name, inactive proper = attic.
>>> 
>>> So:
>>> 
>>> * Proposal #1: Create a Commons Attic.
>>> 
>>> An alternative is to send our attic'd items to the Apache Attic; but I
>>> think we're enough of a mini-ecosystem that it makes sense to manage
>>> our Attic'd components locally. Moving into the Commons Attic would be
>>> very simple; we'd keep permissions etc and do more around updating the
>>> components website to indicate it's now in the Attic. We might go as
>>> far as to close down its JIRA.
>>> 
>>> Next up is to identify the first candidate to a Commons Attic. Jelly
>>> is the lucky winner (by looking at dates in SVN).
>>> 
>>> It hasn't had a commit in a year, and its last meaningful commit (to a
>>> user) was in December 2008.
>>> 
>>> So:
>>> 
>>> * Proposal #2:  Move Jelly to Commons Attic.
>>> 
>>> 
>>> Hen
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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


Mime
View raw message