You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Oliver Zeigermann <oz...@apache.org> on 2010/03/28 11:41:06 UTC
Future of Transaction subproject
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by Phil Steitz <ph...@gmail.com>.
Oliver Zeigermann wrote:
> This seems to ask a more general question and it is an important one:
> How to retire components that have releases?
>
> Do we want to settle this more generally, before we proceed with
> retiring this component?
I agree we should solve the general problem and I think there are
good ideas on this thread about how to do that. Here is what I think:
1) I agree with those who have said that the attic is not
appropriate for inactive commons components that have had releases.
2) I do not like the words "retire" or "retired." The present case
is extreme; but in general it is not correct to assume that the
component will never be re-activated, nor do we want people to get
the impression that revival is impossible. Especially if we get
more aggressive in identifying inactive components, we should be
expecting and welcoming the prospect of components going inactive
and then coming back to life. I would prefer to stick with either
"dormant" or "inactive."
3) I agree that we should separate sandbox dormant|inactive from
proper dormant|inactive
Phil
>
> If so: How do we settle this? I am a little bit afraid that the
> discussion leads to nothing blocking *any* action.
>
> What do you think?
>
> Oliver
>
> 2010/4/16 Paul Benedict <pb...@apache.org>:
>> We could also push the projects into the Apache Attic.
>>
>> 2010/4/16 Niall Pemberton <ni...@gmail.com>:
>>> 2010/4/5 Oliver Zeigermann <ol...@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 <pb...@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 <fl...@gmail.com>:
>>>>>> 2010/3/28 Phil Steitz <ph...@gmail.com>:
>>>>>>> Niall Pemberton wrote:
>>>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>>>>>>>>> 2010/3/28 Rafał Krupiński <r....@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by Oliver Zeigermann <ol...@gmail.com>.
This seems to ask a more general question and it is an important one:
How to retire components that have releases?
Do we want to settle this more generally, before we proceed with
retiring this component?
If so: How do we settle this? I am a little bit afraid that the
discussion leads to nothing blocking *any* action.
What do you think?
Oliver
2010/4/16 Paul Benedict <pb...@apache.org>:
> We could also push the projects into the Apache Attic.
>
> 2010/4/16 Niall Pemberton <ni...@gmail.com>:
>> 2010/4/5 Oliver Zeigermann <ol...@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 <pb...@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 <fl...@gmail.com>:
>>>>> 2010/3/28 Phil Steitz <ph...@gmail.com>:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>>>>>>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by Paul Benedict <pb...@apache.org>.
Sebb, that's a good idea. Three categories seems important: sandbox,
active, retired.
I suppose Commons should agree what is a retired component: a
component without any release for 3 years?
2010/4/16 sebb:
> On 16/04/2010, Paul Benedict <pb...@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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by sebb <se...@gmail.com>.
On 16/04/2010, Paul Benedict <pb...@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 <ni...@gmail.com>:
>
> > 2010/4/5 Oliver Zeigermann <ol...@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 <pb...@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 <fl...@gmail.com>:
> >>>> 2010/3/28 Phil Steitz <ph...@gmail.com>:
> >>>>> Niall Pemberton wrote:
> >>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
> >>>>>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by Paul Benedict <pb...@apache.org>.
We could also push the projects into the Apache Attic.
2010/4/16 Niall Pemberton <ni...@gmail.com>:
> 2010/4/5 Oliver Zeigermann <ol...@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 <pb...@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 <fl...@gmail.com>:
>>>> 2010/3/28 Phil Steitz <ph...@gmail.com>:
>>>>> Niall Pemberton wrote:
>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>>>>>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by Niall Pemberton <ni...@gmail.com>.
2010/4/5 Oliver Zeigermann <ol...@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 <pb...@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 <fl...@gmail.com>:
>>> 2010/3/28 Phil Steitz <ph...@gmail.com>:
>>>> Niall Pemberton wrote:
>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>>>>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by James Carman <ja...@carmanconsulting.com>.
http://svn.apache.org/repos/asf/commons/dormant/transaction/
On Mon, Sep 9, 2013 at 5:53 PM, Bernd Eckenfels <ec...@zusammenkunft.net> wrote:
> Am 09.09.2013, 23:01 Uhr, schrieb TylsBurt <a4...@drdrb.com>:
>
>> I am incredulous that nobody wants to know *why* the main target of the
>> project (file atomic transactions) cannot be achieved..
>
>
> Some file operations on some file systems/OS can be atomic (or even
> transactional) - but a lot of them are not accesible from the java class
> library (for example you cannot open a file with O_EXCL).
>
> Real (to other components visible) transactions require special file systems
> (for example TxF NTFS on Windows) which have their own APIs. Using pure java
> the most transacitional semantics could be implemented with networked
> filesystems (speaking NFS, iSCSI or DRDB protocols come to mind).
>
> But on local filesystems, even for native code having a portable crash safe
> io library is next to impossible (especially if you want to also address
> common OS and Disk problems liek write barriers, reordering and lying
> devices).
>
> You can of course simulate some multi operation transactional properties
> (especially if all clients cooperate with the same schema). This is what
> XADisk and other (locking) schemes expect. This might be enough for some
> needs, but it is not what others expect (and most likely does not survive
> all failure modes).
>
> If you only need a transactional storage in a cooperative environment, it
> would be best to use one of the existing RDB MS.
>
> BTW: the discussion thread seems to be 3 years old. I was actually not aware
> of the state of commons transaction.file. The project homepage list it as
> "Dormant", the SVN links exist but dont work. Is there maybe an option to
> have the site to link to "archive" Download and SVN sites (removing binaries
> from the regular dl section)?
>
> Gruss
> Bernd
>
>
> ---------------------------------------------------------------------
> 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
Re: Future of Transaction subproject
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Am 09.09.2013, 23:01 Uhr, schrieb TylsBurt <a4...@drdrb.com>:
> I am incredulous that nobody wants to know *why* the main target of the
> project (file atomic transactions) cannot be achieved..
Some file operations on some file systems/OS can be atomic (or even
transactional) - but a lot of them are not accesible from the java class
library (for example you cannot open a file with O_EXCL).
Real (to other components visible) transactions require special file
systems (for example TxF NTFS on Windows) which have their own APIs. Using
pure java the most transacitional semantics could be implemented with
networked filesystems (speaking NFS, iSCSI or DRDB protocols come to mind).
But on local filesystems, even for native code having a portable crash
safe io library is next to impossible (especially if you want to also
address common OS and Disk problems liek write barriers, reordering and
lying devices).
You can of course simulate some multi operation transactional properties
(especially if all clients cooperate with the same schema). This is what
XADisk and other (locking) schemes expect. This might be enough for some
needs, but it is not what others expect (and most likely does not survive
all failure modes).
If you only need a transactional storage in a cooperative environment, it
would be best to use one of the existing RDB MS.
BTW: the discussion thread seems to be 3 years old. I was actually not
aware of the state of commons transaction.file. The project homepage list
it as "Dormant", the SVN links exist but dont work. Is there maybe an
option to have the site to link to "archive" Download and SVN sites
(removing binaries from the regular dl section)?
Gruss
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by TylsBurt <a4...@drdrb.com>.
Oliver Zeigermann wrote
> 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
Yeah
I am incredulous that nobody wants to know *why* the main target of the
project (file atomic transactions) cannot be achieved..
Could you provide an explanation to such impossibility?
How is it possibile that other projects (e.g. XADisk) can achive atomicity?
Thank you
--
View this message in context: http://apache-commons.680414.n4.nabble.com/Future-of-Transaction-subproject-tp1693997p4653677.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by Bill Barker <bi...@verizon.net>.
--------------------------------------------------
From: "Henri Yandell" <fl...@gmail.com>
Sent: Tuesday, April 06, 2010 9:18 PM
To: "Commons Developers List" <de...@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 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 <ol...@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 <pb...@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 <fl...@gmail.com>:
>>>> 2010/3/28 Phil Steitz <ph...@gmail.com>:
>>>>> Niall Pemberton wrote:
>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com>
>>>>>> wrote:
>>>>>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by Henri Yandell <fl...@gmail.com>.
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 <ol...@gmail.com>:
> 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 <fl...@gmail.com>:
>> 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 <ol...@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 <pb...@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 <fl...@gmail.com>:
>>>>> 2010/3/28 Phil Steitz <ph...@gmail.com>:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>>>>>>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by Oliver Zeigermann <ol...@gmail.com>.
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 <fl...@gmail.com>:
> 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 <ol...@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 <pb...@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 <fl...@gmail.com>:
>>>> 2010/3/28 Phil Steitz <ph...@gmail.com>:
>>>>> Niall Pemberton wrote:
>>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>>>>>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by Oliver Zeigermann <ol...@gmail.com>.
I have added a JIRA entry for the full retiring process now:
https://issues.apache.org/jira/browse/TRANSACTION-39
2010/4/16 sebb <se...@gmail.com>:
> On 16/04/2010, Oliver Zeigermann <ol...@gmail.com> wrote:
>> 2010/4/16 sebb <se...@gmail.com>:
>>
>> >> > * 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: 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
Re: Future of Transaction subproject
Posted by sebb <se...@gmail.com>.
On 16/04/2010, Oliver Zeigermann <ol...@gmail.com> wrote:
> 2010/4/16 sebb <se...@gmail.com>:
>
> >> > * 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: 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
Re: Future of Transaction subproject
Posted by Oliver Zeigermann <ol...@gmail.com>.
2010/4/16 sebb <se...@gmail.com>:
>> > * 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by sebb <se...@gmail.com>.
On 16/04/2010, Oliver Zeigermann <ol...@gmail.com> wrote:
> OK, so I have done some initial steps. Details are inline below:
>
> 2010/4/7 Henri Yandell <fl...@gmail.com>:
>
> > * 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: 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
Re: Future of Transaction subproject
Posted by Oliver Zeigermann <ol...@gmail.com>.
OK, so I have done some initial steps. Details are inline below:
2010/4/7 Henri Yandell <fl...@gmail.com>:
> * 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by Rahul Akolkar <ra...@gmail.com>.
On Wed, Apr 7, 2010 at 5:09 AM, Jochen Wiedmann
<jo...@gmail.com> wrote:
> 2010/4/7 Henri Yandell <fl...@gmail.com>:
>
>> * 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by Jochen Wiedmann <jo...@gmail.com>.
2010/4/7 Henri Yandell <fl...@gmail.com>:
> * 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by Henri Yandell <fl...@gmail.com>.
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 <ol...@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 <pb...@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 <fl...@gmail.com>:
>>> 2010/3/28 Phil Steitz <ph...@gmail.com>:
>>>> Niall Pemberton wrote:
>>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>>>>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by Oliver Zeigermann <ol...@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 <pb...@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 <fl...@gmail.com>:
>> 2010/3/28 Phil Steitz <ph...@gmail.com>:
>>> Niall Pemberton wrote:
>>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>>>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by Paul Benedict <pb...@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 <fl...@gmail.com>:
> 2010/3/28 Phil Steitz <ph...@gmail.com>:
>> Niall Pemberton wrote:
>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by Henri Yandell <fl...@gmail.com>.
2010/3/28 Phil Steitz <ph...@gmail.com>:
> Niall Pemberton wrote:
>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>>> 2010/3/28 Rafał Krupiński <r....@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
Re: Future of Transaction subproject
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
>> 2010/3/28 Rafał Krupiński <r....@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. :)
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by Niall Pemberton <ni...@gmail.com>.
On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell <fl...@gmail.com> wrote:
> 2010/3/28 Rafał Krupiński <r....@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.
Niall
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by Henri Yandell <fl...@gmail.com>.
2010/3/28 Rafał Krupiński <r....@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.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by Rafał Krupiński <r....@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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Future of Transaction subproject
Posted by Henri Yandell <fl...@gmail.com>.
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
<oz...@apache.org> 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: 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