http://svn.apache.org/repos/asf/commons/dormant/transaction/
On Mon, Sep 9, 2013 at 5:53 PM, Bernd Eckenfels wrote:
> Am 09.09.2013, 23:01 Uhr, schrieb TylsBurt :
>
>> I am incredulous that nobody wants to know *why* the main target of the
>> project (file atomic transactions) cannot be achieved
Am 09.09.2013, 23:01 Uhr, schrieb TylsBurt :
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
t 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/Fut
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 t
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 wrote:
>> We could also push the projects into the Apache
On 16/04/2010, Paul Benedict 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 probab
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
We could also push the projects into the Apache Attic.
2010/4/16 Niall Pemberton :
> 2010/4/5 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
2010/4/5 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 ret
I have added a JIRA entry for the full retiring process now:
https://issues.apache.org/jira/browse/TRANSACTION-39
2010/4/16 sebb :
> On 16/04/2010, Oliver Zeigermann wrote:
>> 2010/4/16 sebb :
>>
>> >> > * Tempted to leave the SVN as is, but make it read-only; rather than
>> >> > do a move to
On 16/04/2010, Oliver Zeigermann wrote:
> 2010/4/16 sebb :
>
> >> > * 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
2010/4/16 sebb :
>> > * 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 s
On 16/04/2010, Oliver Zeigermann wrote:
> OK, so I have done some initial steps. Details are inline below:
>
> 2010/4/7 Henri Yandell :
>
> > * 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 u
OK, so I have done some initial steps. Details are inline below:
2010/4/7 Henri Yandell :
> * 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
On Wed, Apr 7, 2010 at 5:09 AM, Jochen Wiedmann
wrote:
> 2010/4/7 Henri Yandell :
>
>> * 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 committ
2010/4/7 Henri Yandell :
> * 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 wo
--
From: "Henri Yandell"
Sent: Tuesday, April 06, 2010 9:18 PM
To: "Commons Developers List"
Subject: Re: Future of Transaction subproject
My method when consensus seems very likely but you want to ensure it's
expli
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 :
> That sounds reasonable.
>
> I will be off for a week or so, and might need s
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 :
> My method when consensus seems very likely but you want to ensure it's
> explicit
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 cas
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
+1 to push any inactive projects to the attic. they can always be
moved back if real activity begins.
2010/3/28 Henri Yandell :
> 2010/3/28 Phil Steitz :
>> Niall Pemberton wrote:
>>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell wrote:
2010/3/28 Rafał Krupiński :
> On 28.03.2010 20:13,
2010/3/28 Phil Steitz :
> Niall Pemberton wrote:
>> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell wrote:
>>> 2010/3/28 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
Niall Pemberton wrote:
> On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell wrote:
>> 2010/3/28 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
>>>
On Sun, Mar 28, 2010 at 7:22 PM, Henri Yandell wrote:
> 2010/3/28 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 mor
2010/3/28 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 (Att
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).
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
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 inc
29 matches
Mail list logo
