Future of Transaction subproject

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Future of Transaction subproject

ozeigermann
Folks!

While developing the 2.0 version of commons transaction I got stuck on
implementing a usable transactional file system. As I am convinced
this is not possible on top of an ordinary file system I suggest to
retire the project. Although there are other useful parts (as multi
level locking including deadlock detection) the transactional file
system is the main reason people use this library for. As it simply
can not be made fully transactional, it does not work as advertised
and for that reason it should be taken off from Apache commons.

I will not invest more work into the project, but if anyone else is
willing to take this any further please follow up to this post.

Cheers

- Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Henri Yandell
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).

Are the other useful parts worth putting in another library?

On Sun, Mar 28, 2010 at 2:41 AM, Oliver Zeigermann
<[hidden email]> wrote:

> Folks!
>
> While developing the 2.0 version of commons transaction I got stuck on
> implementing a usable transactional file system. As I am convinced
> this is not possible on top of an ordinary file system I suggest to
> retire the project. Although there are other useful parts (as multi
> level locking including deadlock detection) the transactional file
> system is the main reason people use this library for. As it simply
> can not be made fully transactional, it does not work as advertised
> and for that reason it should be taken off from Apache commons.
>
> I will not invest more work into the project, but if anyone else is
> willing to take this any further please follow up to this post.
>
> Cheers
>
> - Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Rafał Krupiński
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?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Henri Yandell
2010/3/28 Rafał Krupiński <[hidden email]>:
> 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.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Niall Pemberton
On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <[hidden email]> wrote:

> 2010/3/28 Rafał Krupiński <[hidden email]>:
>> 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.

Niall

> Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Phil Steitz
Niall Pemberton wrote:

> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <[hidden email]> wrote:
>> 2010/3/28 Rafał Krupiński <[hidden email]>:
>>> 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. :)

Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Henri Yandell
2010/3/28 Phil Steitz <[hidden email]>:

> Niall Pemberton wrote:
>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <[hidden email]> wrote:
>>> 2010/3/28 Rafał Krupiński <[hidden email]>:
>>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Paul Benedict
+1 to push any inactive projects to the attic. they can always be
moved back if real activity begins.

2010/3/28 Henri Yandell <[hidden email]>:

> 2010/3/28 Phil Steitz <[hidden email]>:
>> Niall Pemberton wrote:
>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <[hidden email]> wrote:
>>>> 2010/3/28 Rafał Krupiński <[hidden email]>:
>>>>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Oliver Zeigermann
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 <[hidden email]>:

> +1 to push any inactive projects to the attic. they can always be
> moved back if real activity begins.
>
> 2010/3/28 Henri Yandell <[hidden email]>:
>> 2010/3/28 Phil Steitz <[hidden email]>:
>>> Niall Pemberton wrote:
>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <[hidden email]> wrote:
>>>>> 2010/3/28 Rafał Krupiński <[hidden email]>:
>>>>>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Henri Yandell
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 announce@.

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

Hen

2010/4/5 Oliver Zeigermann <[hidden email]>:

> 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 <[hidden email]>:
>> +1 to push any inactive projects to the attic. they can always be
>> moved back if real activity begins.
>>
>> 2010/3/28 Henri Yandell <[hidden email]>:
>>> 2010/3/28 Phil Steitz <[hidden email]>:
>>>> Niall Pemberton wrote:
>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <[hidden email]> wrote:
>>>>>> 2010/3/28 Rafał Krupiński <[hidden email]>:
>>>>>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Oliver Zeigermann
That sounds reasonable.

I will be off for a week or so, and might need some help to accomplish
the task. Maybe we can retire the concerned projects in a bulk and
share the work?

- Oliver

2010/4/7 Henri Yandell <[hidden email]>:

> 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 announce@.
>
> * 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)
>
> Hen
>
> 2010/4/5 Oliver Zeigermann <[hidden email]>:
>> 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 <[hidden email]>:
>>> +1 to push any inactive projects to the attic. they can always be
>>> moved back if real activity begins.
>>>
>>> 2010/3/28 Henri Yandell <[hidden email]>:
>>>> 2010/3/28 Phil Steitz <[hidden email]>:
>>>>> Niall Pemberton wrote:
>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <[hidden email]> wrote:
>>>>>>> 2010/3/28 Rafał Krupiński <[hidden email]>:
>>>>>>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Henri Yandell
Absolutely. :)

Go ahead and get things started by writing up something for the
transaction website, then we can proceed from there.

I'll come up with a change for the Attributes site.

Hen

2010/4/6 Oliver Zeigermann <[hidden email]>:

> That sounds reasonable.
>
> I will be off for a week or so, and might need some help to accomplish
> the task. Maybe we can retire the concerned projects in a bulk and
> share the work?
>
> - Oliver
>
> 2010/4/7 Henri Yandell <[hidden email]>:
>> 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 announce@.
>>
>> * 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)
>>
>> Hen
>>
>> 2010/4/5 Oliver Zeigermann <[hidden email]>:
>>> 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 <[hidden email]>:
>>>> +1 to push any inactive projects to the attic. they can always be
>>>> moved back if real activity begins.
>>>>
>>>> 2010/3/28 Henri Yandell <[hidden email]>:
>>>>> 2010/3/28 Phil Steitz <[hidden email]>:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <[hidden email]> wrote:
>>>>>>>> 2010/3/28 Rafał Krupiński <[hidden email]>:
>>>>>>>>> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Bill Barker
In reply to this post by Henri Yandell


--------------------------------------------------
From: "Henri Yandell" <[hidden email]>
Sent: Tuesday, April 06, 2010 9:18 PM
To: "Commons Developers List" <[hidden email]>
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 announce@.
>
> * 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 <[hidden email]>:
>> 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 <[hidden email]>:
>>> +1 to push any inactive projects to the attic. they can always be
>>> moved back if real activity begins.
>>>
>>> 2010/3/28 Henri Yandell <[hidden email]>:
>>>> 2010/3/28 Phil Steitz <[hidden email]>:
>>>>> Niall Pemberton wrote:
>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <[hidden email]>
>>>>>> wrote:
>>>>>>> 2010/3/28 Rafał Krupiński <[hidden email]>:
>>>>>>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

jochen-2
In reply to this post by Henri Yandell
2010/4/7 Henri Yandell <[hidden email]>:

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

Disagree with that point. A committer can be expected to deal with SVN
moves, otherwise he or she won't be able to deal with branches. And
for the user it is best to have a clear distinction between sandbox,
proper and dormant. (Whether we call it dormant, retired, or whatever
doesn't matter.)

Jochen


--
Germanys national anthem is the most boring in the world - how telling!

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Rahul Akolkar
On Wed, Apr 7, 2010 at 5:09 AM, Jochen Wiedmann
<[hidden email]> wrote:

> 2010/4/7 Henri Yandell <[hidden email]>:
>
>> * 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.
>
> Disagree with that point. A committer can be expected to deal with SVN
> moves, otherwise he or she won't be able to deal with branches. And
> for the user it is best to have a clear distinction between sandbox,
> proper and dormant. (Whether we call it dormant, retired, or whatever
> doesn't matter.)
>
<snip/>

I say move out of proper in SVN (to dormant / retired / TBD) as well.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Oliver Zeigermann
In reply to this post by Henri Yandell
OK, so I have done some initial steps. Details are inline below:

2010/4/7 Henri Yandell <[hidden email]>:
> * 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.

Source have been updated with a suitable explanation, but not yet
uploaded. Not sure how to move the whole project into the dormant
section of the site though. Any advise?

> * Should send an email out to commons-user/dev at the very least. Not
> sure if we need to email announce@.

Will do once we are through with all changes.

> * Make the JIRA read-only.

No idea how to do that?! Can someone else do that?

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

I think the consensus more or less was to move it into svn dormant, right?

Can I simply check out the whole proper/transaction sub directory and
then move it to dormant/transaction? Or will that mess up any
tagging/branches?

> * Remove from the trunks-proper svn:externals.

Done and added it to externals for trunks-dormant (needs to be updated
once project has moved to dormant in svn).

>
> * Remove from CI systems + Gump.

No idea how to do that either. Can someone else do that? (same as jira
read only)

> I think there are a few others to retire:
>
> # Attributes.
> # Discovery
> # Modeler (consider)
> # Launcher (consider)
> # Betwixt (consider)

What about these?

- Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

sebb-2-2
On 16/04/2010, Oliver Zeigermann <[hidden email]> wrote:

> OK, so I have done some initial steps. Details are inline below:
>
>  2010/4/7 Henri Yandell <[hidden email]>:
>
> > * 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.
>
>
> Source have been updated with a suitable explanation, but not yet
>  uploaded. Not sure how to move the whole project into the dormant
>  section of the site though. Any advise?
>
>
>  > * Should send an email out to commons-user/dev at the very least. Not
>  > sure if we need to email announce@.
>
>
> Will do once we are through with all changes.
>
>
>  > * Make the JIRA read-only.
>
>
> No idea how to do that?! Can someone else do that?
>
>
>  > * 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.
>
>
> I think the consensus more or less was to move it into svn dormant, right?
>
>  Can I simply check out the whole proper/transaction sub directory and
>  then move it to dormant/transaction? Or will that mess up any
>  tagging/branches?

Yes, that will mess up history too. The following command:

svn move -m"Transaction => Dormant" oldurl newurl

where oldurl/newurl are the https: urls

should do the trick whilst maintaining history.

>
>  > * Remove from the trunks-proper svn:externals.
>
>
> Done and added it to externals for trunks-dormant (needs to be updated
>  once project has moved to dormant in svn).
>
>
>  >
>  > * Remove from CI systems + Gump.
>
>
> No idea how to do that either. Can someone else do that? (same as jira
>  read only)
>

I can do that - just means deleting the Continuum entry and the Gump
entry from projects/commons-proper.xml (or whatever it is called).

>  > I think there are a few others to retire:
>  >
>  > # Attributes.
>  > # Discovery
>  > # Modeler (consider)
>  > # Launcher (consider)
>  > # Betwixt (consider)
>
>
> What about these?
>
>
>  - Oliver
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Oliver Zeigermann
2010/4/16 sebb <[hidden email]>:

>>  > * 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.
>>
>>
>> I think the consensus more or less was to move it into svn dormant, right?
>>
>>  Can I simply check out the whole proper/transaction sub directory and
>>  then move it to dormant/transaction? Or will that mess up any
>>  tagging/branches?
>
> Yes, that will mess up history too. The following command:
>
> svn move -m"Transaction => Dormant" oldurl newurl
>
> where oldurl/newurl are the https: urls
>
> should do the trick whilst maintaining history.

OK, cool, will do.

>>  > * Remove from CI systems + Gump.
>>
>>
>> No idea how to do that either. Can someone else do that? (same as jira
>>  read only)
>>
>
> I can do that - just means deleting the Continuum entry and the Gump
> entry from projects/commons-proper.xml (or whatever it is called).

Great, please do so.

- Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

sebb-2-2
On 16/04/2010, Oliver Zeigermann <[hidden email]> wrote:

> 2010/4/16 sebb <[hidden email]>:
>
> >>  > * 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.
>  >>
>  >>
>  >> I think the consensus more or less was to move it into svn dormant, right?
>  >>
>  >>  Can I simply check out the whole proper/transaction sub directory and
>  >>  then move it to dormant/transaction? Or will that mess up any
>  >>  tagging/branches?
>  >
>  > Yes, that will mess up history too. The following command:
>  >
>  > svn move -m"Transaction => Dormant" oldurl newurl
>  >
>  > where oldurl/newurl are the https: urls
>  >
>  > should do the trick whilst maintaining history.
>
>
> OK, cool, will do.
>
>
>  >>  > * Remove from CI systems + Gump.
>  >>
>  >>
>  >> No idea how to do that either. Can someone else do that? (same as jira
>  >>  read only)
>  >>
>  >
>  > I can do that - just means deleting the Continuum entry and the Gump
>  > entry from projects/commons-proper.xml (or whatever it is called).
>
>
> Great, please do so.
>

Is there a JIRA entry for this work?

It would be useful as a way to keep track of the individual tasks, and
we can then use it as a base for any future moves.

>  - Oliver
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future of Transaction subproject

Oliver Zeigermann
I have added a JIRA entry for the full retiring process now:

https://issues.apache.org/jira/browse/TRANSACTION-39

2010/4/16 sebb <[hidden email]>:

> On 16/04/2010, Oliver Zeigermann <[hidden email]> wrote:
>> 2010/4/16 sebb <[hidden email]>:
>>
>> >>  > * 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.
>>  >>
>>  >>
>>  >> I think the consensus more or less was to move it into svn dormant, right?
>>  >>
>>  >>  Can I simply check out the whole proper/transaction sub directory and
>>  >>  then move it to dormant/transaction? Or will that mess up any
>>  >>  tagging/branches?
>>  >
>>  > Yes, that will mess up history too. The following command:
>>  >
>>  > svn move -m"Transaction => Dormant" oldurl newurl
>>  >
>>  > where oldurl/newurl are the https: urls
>>  >
>>  > should do the trick whilst maintaining history.
>>
>>
>> OK, cool, will do.
>>
>>
>>  >>  > * Remove from CI systems + Gump.
>>  >>
>>  >>
>>  >> No idea how to do that either. Can someone else do that? (same as jira
>>  >>  read only)
>>  >>
>>  >
>>  > I can do that - just means deleting the Continuum entry and the Gump
>>  > entry from projects/commons-proper.xml (or whatever it is called).
>>
>>
>> Great, please do so.
>>
>
> Is there a JIRA entry for this work?
>
> It would be useful as a way to keep track of the individual tasks, and
> we can then use it as a base for any future moves.
>
>>  - Oliver
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: [hidden email]
>>  For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12