On Wed, Aug 24, 2011 at 4:26 AM, Ivan Zhakov <[email protected]> wrote: > On Wed, Aug 24, 2011 at 12:38, Bert Huijben <[email protected]> wrote: >> >> >>> -----Original Message----- >>> From: Stefan Sperling [mailto:[email protected]] >>> Sent: woensdag 24 augustus 2011 9:50 >>> To: Markus Schaber >>> Cc: [email protected] >>> Subject: Re: rc1 is DOA. What now? >>> >>> On Wed, Aug 24, 2011 at 08:46:17AM +0200, Markus Schaber wrote: >>> > To support this unlocking, it would additionally force our software to >>> > carry both SVN 1.6 and SVN 1.7 libraries at the same time. >>> >>> If 1.7.0 was released with this upgrade bug, you would simply have to >>> wait for a 1.7.x patch release which fixes the bug before upgrading >>> from 1.6.x. >>> >>> This is basically just like any other show stopper you might find >>> during the upgrade to 1.7. Except that you already know about it now :) >>> >>> But I understand your complaints and agree that the problem needs >>> to be fixed in 1.7.x eventually. >> >> * The average TortoiseSVN user in a corporate environment can't >> upgrade/downgrade its own installation as that as managed via automated >> distribution. >> * TortoiseSVN versions can't be installed side by side. >> (The same problem applies to big multi user installations on shared linux >> installations using plain svn) >> >> How would you answer an e-mail from your sysadmin that tonight before you go >> home you have to remove all locks from all your working copies because >> otherwise tomorrow your working copies are broken? >> (Assuming you have over 40 independent working copies, not counting possible >> directory externals, like I had when I worked at TCG) >> >> >> I call this a show stopper; and as I suggested before suggesting these users >> to wait until 1.7.1 is the same as calling this a show stopper. >> And it also breaks the perfect stability track record we had with a >> known-in-advance broken release. >> >> In my opinion this issue must be fixed by 1.7.0. >> > I fully agree with Bert: this upgrade bug is show stopper for 1.7.0. I > do not see the problem with restarting soak period because we found > bugs: this is purpose soak period and stabilization to release > software without known important issues.
To be clear: this type of bug would not have restarted the 4-week soak if we'd already been in it. It is well-understood and the fix is well-scoped. While I don't claim it has been tested exhaustively, restarting the soak is reserved for high-impact fixes which require a large degree of community testing. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
