[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r37902 - trunk

From: Hyrum K. Wright <hyrum_at_hyrumwright.org>
Date: Sat, 30 May 2009 10:45:15 -0500

On May 30, 2009, at 10:08 AM, Arfrever Frehtes Taifersar Arahesis wrote:

> 2009-05-30 14:20:12 Hyrum K. Wright napisał(a):
>> On May 29, 2009, at 8:45 PM, Mark Phippard wrote:
>>> On Fri, May 29, 2009 at 7:37 PM, Hyrum K. Wright <hyrum_at_hyrumwright.org
>>>> wrote:
>>>> On May 29, 2009, at 5:44 PM, Arfrever Frehtes Taifersar Arahesis
>>>> wrote:
>>>>> 2009-05-29 23:54:58 Hyrum K. Wright napisał(a):
>>>>>> There are a couple of fixes already merged to 1.6.x which fix
>>>>>> bugs
>>>>>> which we've been hearing about a lot lately (I'm looking at you,
>>>>>> r37894). If nobody objects, I'd like to cut 1.6.3 early this
>>>>>> upcoming
>>>>>> Wednesday, in an effort to get these fixes out there quickly. I
>>>>>> realize this comes pretty quickly on the heals of 1.6.2, but I
>>>>>> feel
>>>>>> the fixes are important enough to do a quick release.
>>>>> IMHO it would be better to release 1.6.3 30 days after the release
>>>>> of 1.6.2.
>>>> Would you care to #define that magic number? :)
>>> Barring some kind of data loss bug, there is something to be said
>>> for
>>> just sticking to a rhythm. I agree that some of the fixes since
>>> 1.6.2
>>> are particularly high value, so I would not object to a release next
>>> week. That said, I also think it could wait another week or 2 as
>>> planned to see what other fixes get in and to allow for proper
>>> review
>>> of anything else.
>>> There was that thread on the problem with copy, as an example. Will
>>> it be fixed in the next week? I'd guess no, but maybe it is getting
>>> some attention now. Were a fix to come in say in a week it sure
>>> would
>>> be nice to get it in to 1.6.3 (as well as a 1.5.x release).
>>> Anyway, no objections from me, just saying that I also think there
>>> is
>>> merit in sticking with the "plan".
>> The "plan" has always been a bit loosely defined, but I've generally
>> been going with 6-8 week point releases. In this case, it seems like
>> lots of people have been hit by the "commit takes too much memory"
>> bug, for which we believe we have a fix already merged to 1.6.x.
>> That's the primary reason why I'd want to do a 1.6.3 next week, since
>> it's a real issue that has been hindering people's ability to use
>> Subversion.
>> That being said, I agree that there is a real cost to cutting a
>> release, and we should try to avoid too frequent releases. I was
>> really just wondering why rolling the tarball on June 5 would be to
>> much different (from Arfrever's perspective) than rolling it on
>> June 3.
> Subversion 1.6.2 was released on 2009-05-11 11:55 UTC, so 30 days
> later
> is 2009-06-10.

Meh. Well, from my perspective it's when we create the release
tarball that matters, rather than the nondeterministic amount of time
it requires for us to collect sigs. Fixes that went into 1.6.x on
2009-05-09 aren't part of the 1.6.2 release, and the magic rev
certainly didn't happen on 2009-05-11. (I'm not saying this is the
only way to look at it; your perspective is valid from a users point-
of-view, but as an RM, I care about when we create the tarball, not
when it is announced.)

Oh, and I still don't see a good rationale for that particular date.
Do you see a particular fix getting into 1.6.x between June 3 and June


Received on 2009-05-30 17:45:34 CEST

This is an archived mail posted to the Subversion Dev mailing list.