[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: Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA_at_GMail.Com>
Date: Sun, 31 May 2009 16:43:52 +0200

2009-05-30 17:45:15 Hyrum K. Wright napisa³(a):
>
> 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.)

The "1.6.2 tarballs up for signing/testing" thread was started on
2009-05-07 16:49 UTC, so I'm +1 for creating 1.6.3 tarball 30 days
later, i.e. on 2009-06-06 :) .

-- 
Arfrever Frehtes Taifersar Arahesis

Received on 2009-05-31 16:43:11 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.