commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Future of Transaction subproject
Date Fri, 16 Apr 2010 16:25:22 GMT
On 16/04/2010, Paul Benedict <pbenedict@apache.org> wrote:
> We could also push the projects into the Apache Attic.

However they are not strictly projects, but components of the Commons project.
Since there is still a Commons community, I think the Attic is unnecessary here.

But I agree with Niall that it would probably be worth distinguishing
components that have been released from ones that have not.

commons/retired
or even
commons/attic

would be fine by me.

>  2010/4/16 Niall Pemberton <niall.pemberton@gmail.com>:
>
> > 2010/4/5 Oliver Zeigermann <oliver.zeigermann@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.
>  >
>  > Up to now everything in dormant has been sandbox components that were
>  > never released. In my mind *retiring* a proper component that has had
>  > releases is different from a sandbox component that became inactive.
>  > I'm wondering if we should distinguish between these two scenarios
>  > rather than just putting them all together in dormant?
>  >
>  > Niall
>  >
>  >
>  >> What are the next steps? Do we need a formal vote? Or are we just doing it?
>  >>
>  >> - Oliver
>  >>
>  >> 2010/3/29 Paul Benedict <pbenedict@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 <flamefew@gmail.com>:
>  >>>> 2010/3/28 Phil Steitz <phil.steitz@gmail.com>:
>  >>>>> Niall Pemberton wrote:
>  >>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <flamefew@gmail.com>
wrote:
>  >>>>>>> 2010/3/28 Rafał Krupiński <r.krupinski@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-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
>  >>
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > 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