commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [ALL] Commons Attic
Date Mon, 11 Apr 2011 15:05:52 GMT
On Mon, Apr 11, 2011 at 10:58 AM, Phil Steitz <phil.steitz@gmail.com> 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.
>

Perhaps a Commons Meter page showing project activity based on commits, ML
traffic and JIRA would be help users visualize and decide how active things
are.

Gary


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


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message