commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [ALL] Commons Attic
Date Mon, 11 Apr 2011 14:58:44 GMT
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


Mime
View raw message