On Mon, Apr 11, 2011 at 10:58 AM, Phil Steitz <phil.ste...@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 <flame...@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-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
