--------------------------------------------------
From: "Henri Yandell" <flame...@gmail.com>
Sent: Tuesday, April 06, 2010 9:18 PM
To: "Commons Developers List" <dev@commons.apache.org>
Subject: Re: Future of Transaction subproject
My method when consensus seems very likely but you want to ensure it's
explicit is to announce you're going to do it in 3 days.
As to the 'it', it means some level of the Attic'ing tasks.
* Definitely should update the website to explain that it's been
retired and why. I don't think this is a case of waiting for community
to show up again (thus why I prefer retired to dormant), we're EOL'ing
the component.
* Should send an email out to commons-user/dev at the very least. Not
sure if we need to email annou...@.
* Make the JIRA read-only.
* Tempted to leave the SVN as is, but make it read-only; rather than
do a move to dormant/. I think we should avoid changing the svn
location of released components.
* Remove from the trunks-proper svn:externals.
* Remove from CI systems + Gump.
I think there are a few others to retire:
# Attributes.
# Discovery
# Modeler (consider)
# Launcher (consider)
# Betwixt (consider)
Yes, #El is also a (consider), since it implements an obsolete version of
the EL spec. And Tomcat is hosting the current implementation of the EL
spec.
Hen
2010/4/5 Oliver Zeigermann <oliver.zeigerm...@gmail.com>:
Folks!
The only discussion seems to be about "how to retire the project", not
"if to retire the project". This means to me we all agree to at least
temporarily retire it and there is no more discussion about how to do
it.
As the Apache commons way of retiring seems to be to move it to the
dormant section that is what I propose.
What are the next steps? Do we need a formal vote? Or are we just doing
it?
- Oliver
2010/3/29 Paul Benedict <pbened...@apache.org>:
+1 to push any inactive projects to the attic. they can always be
moved back if real activity begins.
2010/3/28 Henri Yandell <flame...@gmail.com>:
2010/3/28 Phil Steitz <phil.ste...@gmail.com>:
Niall Pemberton wrote:
On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <flame...@gmail.com>
wrote:
2010/3/28 Rafał Krupiński <r.krupin...@gmail.com>:
On 28.03.2010 20:13, Henri Yandell wrote:
Unless anyone speaks up for it, I'm all for our making a Retired
section and moving Transaction to it. Possibly we could relabel
'Dormant' then to be more Sandbox focused and consider some others
for
Retired (Attributes, Discovery, Modeler jump to mind).
You mean something like Apache Attic?
Fair point. Let's assume moving it to the Attic. I'm not sure it'll
be
a perfect fit, but if it doesn't we can always maintain our own
Retired page.
I guess I shouldn't be telling you how the attic works, but IMO its
for projects which don't have a functioning PMC. Thats not the case
for Commons so I think it would be better to keep *retired*
components
here.
+1 - and I am not sure we can really distinguish "retired" from
"dormant." Not breathing is not breathing and resurrection is
resurrection. :)
Xang went to the Attic from the XML PMC, and Slide + Taglibs (minus
those that went to Tomcat) are expected to go there from Jakarta, so
it's definitely not been limited only to those without PMCs. I think
we could do either option and am not tied to either.
Attic-wise... I was thinking of making a page there, much as Taglibs
will have, which will list retired components.
Commons-wise, we'd have a retired page and probably link to it from
the Attic page as an FYI. So really all we're talking about is the url
for the retired page and the process for restarting a component.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
