Re: svn commit: r1850659 - /subversion/branches/1.7.x/STATUS

[Branko Čibej <br...@apache.org>]

On 07.01.2019 16:35, stsp@apache.org wrote:
> Author: stsp
> Date: Mon Jan  7 15:35:01 2019
> New Revision: 1850659
>
> URL: http://svn.apache.org/viewvc?rev=1850659&view=rev
> Log:
> * STATUS: Nominate r1850651.
>
> Modified:
>     subversion/branches/1.7.x/STATUS

Why this (and the 1.8.x) nomination? We won't create any more releases
from those branches.

Yes I do understand that many distros are still stuck with these ancient
versions.

-- Brane

Re: svn commit: r1850659 - /subversion/branches/1.7.x/STATUS

[Branko Čibej <br...@apache.org>]

On 08.01.2019 11:45, Stefan Sperling wrote:
> On Tue, Jan 08, 2019 at 09:18:21AM +0000, Julian Foad wrote:
>> Branko Čibej wrote:
>>> Why this (and the 1.8.x) nomination?
>> It's useful information, to a few people. In this case, Stefan can answer for
>> himself, but I guess he had done most of the work anyway and might as well
>> record the result of it. In general, if somebody wants to do the work
>> nominating and/or testing, and if it doesn't distract much energy from the
>> rest of us, that's fine. This wasn't a significant distraction to me; I don't
>> intend to review it or do anything with it.
> Yes, I just added it there because the overhead to do so was minimal for me.
> But I didn't mean to ask anyone to invest time in unsupported releases.
> I mainly wanted to see how far back the patch would merge cleanly to get
> some idea how old this bug really is :)

Ack. Makes sense, for some subversion.a.o-specific definition of "sense". :)

-- Brane

Re: svn commit: r1850659 - /subversion/branches/1.7.x/STATUS

[Daniel Shahaf <d....@daniel.shahaf.name>]

Stefan Sperling wrote on Tue, 08 Jan 2019 11:45 +0100:
> I mainly wanted to see how far back the patch would merge cleanly to get
> some idea how old this bug really is :)

Well, for whatever it's worth:

% svn praise subversion/mod_dav_svn/repos.c | grep hmm
 844512     gstein   /* ### hmm. the FS is cleaned up at request cleanup time. "r" might
 839029     gstein      ### own lifetime now. so WHY are we using a string? hmm... */
% echo r$((844512 - 840074)
r4438
% 

So the comment, at least, is pre-1.0.  Presumably that's the
bug's age, too.

Cheers,

Daniel

Re: svn commit: r1850659 - /subversion/branches/1.7.x/STATUS

[Stefan Sperling <st...@elego.de>]

On Tue, Jan 08, 2019 at 09:18:21AM +0000, Julian Foad wrote:
> Branko Čibej wrote:
> > Why this (and the 1.8.x) nomination?
> 
> It's useful information, to a few people. In this case, Stefan can answer for
> himself, but I guess he had done most of the work anyway and might as well
> record the result of it. In general, if somebody wants to do the work
> nominating and/or testing, and if it doesn't distract much energy from the
> rest of us, that's fine. This wasn't a significant distraction to me; I don't
> intend to review it or do anything with it.

Yes, I just added it there because the overhead to do so was minimal for me.
But I didn't mean to ask anyone to invest time in unsupported releases.
I mainly wanted to see how far back the patch would merge cleanly to get
some idea how old this bug really is :)

Re: svn commit: r1850659 - /subversion/branches/1.7.x/STATUS

[Julian Foad <ju...@apache.org>]

Branko Čibej wrote:
> Why this (and the 1.8.x) nomination?

It's useful information, to a few people. In this case, Stefan can answer for himself, but I guess he had done most of the work anyway and might as well record the result of it. In general, if somebody wants to do the work nominating and/or testing, and if it doesn't distract much energy from the rest of us, that's fine. This wasn't a significant distraction to me; I don't intend to review it or do anything with it.

> We won't create any more releases from those branches.

If somebody even wants to create a new release from an unsupported branch, likewise, that's fine too, again with the 'distraction' caveat. In declaring those versions as unsupported, we don't promise never to do anything supportive, and as an open source project we certainly can't prevent others doing so. I would suggest in cases where a tiny action on our part may help other people to do such maintenance if they want to, then it's healthy for us to do that.

-- 
- Julian