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 <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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
