You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Hyrum K Wright <hy...@wandisco.com> on 2011/08/19 20:24:05 UTC
1.7.0-rc1 up for testing / signing
Here it is: the first Release Candidate for Subversion 1.7.0. You can
fetch the proposed tarballs from here:
http://people.apache.org/~hwright/svn/1.7.0-rc1/
The magic rev is r1159696; please post signatures at the normal location:
http://work.hyrumwright.org/pub/svn/collect_sigs.py
This is a release candidate, meaning if all goes well it (or something
very much like it) will become the final release. Please test this as
if it were the final release, understanding that there will be bugs in
any software we ship. <insert lecture about perfect being enemy of
the good here>
To all distributors and binary packagers: This isn't the final
release. It *won't* be the final release for a few weeks yet, so
please don't ship it as such. In any case, don't distribute any
releases based upon these tarballs until we complete our signature
gathering process and officially announce the release.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: rc1 is DOA. What now?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Bert Huijben wrote on Wed, Aug 24, 2011 at 15:18:49 +0200:
>
>
> > -----Original Message-----
> > From: Branko Čibej [mailto:brane@xbc.nu] On Behalf Of Branko Cibej
> > Sent: woensdag 24 augustus 2011 15:07
> > To: Bert Huijben
> > Subject: Re: rc1 is DOA. What now?
> >
> > On 24.08.2011 10:38, Bert Huijben wrote:
> > > 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?
> >
> > I would mail his manager with a suggestion to fire that sysadmin,
> > because he wasn't doing his job right.
> >
> > > 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.
> >
> > You're overreacting. Compare this limitation to all the other
> > limitations of the 1.7 WC upgrade (by the way, where's the list of those
> > anyway?).
>
> The complete list:
> * You can't have loggy items queued in your working copy
>
> All other working copy states are fully supported for upgrade for the step from 1.0-1.6 -> 1.7+
>
> There are unsupported scenarios for the intermediate development formats, but there are no other limitations for the supported formats.
>
> Bert
>
Documented in r1161100.
Re: rc1 is DOA. What now?
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Wed, Aug 24, 2011 at 4:26 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Wed, Aug 24, 2011 at 12:38, Bert Huijben <be...@qqmail.nl> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Stefan Sperling [mailto:stsp@elego.de]
>>> Sent: woensdag 24 augustus 2011 9:50
>>> To: Markus Schaber
>>> Cc: dev@subversion.apache.org
>>> 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/
Re: rc1 is DOA. What now?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, Aug 24, 2011 at 12:38, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Stefan Sperling [mailto:stsp@elego.de]
>> Sent: woensdag 24 augustus 2011 9:50
>> To: Markus Schaber
>> Cc: dev@subversion.apache.org
>> 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.
--
Ivan Zhakov
Re: rc1 is DOA. What now?
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Aug 24, 2011 at 10:01 AM, Mark Phippard <ma...@gmail.com> wrote:
> This is total strawman that you are setting up just so that you can knock
> it down. Hyrum has said on numerous occasions that he can and will merge
> bug fixes prior to creating the final 1.7. As he pointed out in a recent
> reply this was a safe fix that was reviewed. There was nothing that was
> going to prevent this from going into 1.7.0. If you disagree with this
> policy, then start a new thread for it. There are definitely going to be
> bugs found in any RC we release. If we treat all bugs like this we will
> never release. All we have really accomplished is to push this release off
> another week.
>
>From the Community Guide:
"At the beginning of the final week of the stabilization period, a new
release candidate tarball should be made if there are any showstopper
changes pending since the last one. The final week of the stabilization
period is reserved for critical bugfixes; fixes for minor bugs should be
deferred to the A.B.1 release. A critical bug is a non-edge-case crash, a
data corruption problem, a major security hole, or something equally
serious."
http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: rc1 is DOA. What now?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/24/2011 10:01 AM, Mark Phippard wrote:
> As I said before, I bet it would not take me too long looking through our
> open issues in the issue tracker to find a bug that was just as bad as this
> one. If we are going to call bugs like this show stoppers it is going to be
> difficult to ever get the release out.
I won't pretend to speak on behalf of those who've voiced concerns about
this bug, but I wonder if the perceived gravity here is due to extra
sensitivity about the 'upgrade' command as the very first thing users will
try to do with Subversion 1.7. Well, the second thing, after they try to
run 'svn update' and get an error message telling them to upgrade. ;-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: rc1 is DOA. What now?
Posted by Mark Phippard <ma...@gmail.com>.
First off, let me just state that I have already said on several occasions I
am OK with rolling an RC2 and since that seems to be the plan I am +1 to it.
I am not trying to get RC1 released. That said, we could very well wind up
in this same situation again after RC2 is out so I think it is worth
continuing the discussion.
On Wed, Aug 24, 2011 at 4:38 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
> >
> > 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)
>
This is total strawman that you are setting up just so that you can knock it
down. Hyrum has said on numerous occasions that he can and will merge bug
fixes prior to creating the final 1.7. As he pointed out in a recent reply
this was a safe fix that was reviewed. There was nothing that was going to
prevent this from going into 1.7.0. If you disagree with this policy, then
start a new thread for it. There are definitely going to be bugs found in
any RC we release. If we treat all bugs like this we will never release.
All we have really accomplished is to push this release off another week.
Back to the strawman, you create this scenario of a poor admin that is
rolling out an update to all these workstations. Since when do these people
immediately roll out .0 releases? Since when do these people not do any
testing or investigation of their own? Even if this fix did not make it
into a .0 it would have been in a .1. It also does not factor in that users
can still checkout new working copies etc.
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.
>
As I said before, I bet it would not take me too long looking through our
open issues in the issue tracker to find a bug that was just as bad as this
one. If we are going to call bugs like this show stoppers it is going to be
difficult to ever get the release out.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: rc1 is DOA. What now?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@xbc.nu] On Behalf Of Branko Cibej
> Sent: woensdag 24 augustus 2011 15:07
> To: Bert Huijben
> Subject: Re: rc1 is DOA. What now?
>
> On 24.08.2011 10:38, Bert Huijben wrote:
> > 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?
>
> I would mail his manager with a suggestion to fire that sysadmin,
> because he wasn't doing his job right.
>
> > 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.
>
> You're overreacting. Compare this limitation to all the other
> limitations of the 1.7 WC upgrade (by the way, where's the list of those
> anyway?).
The complete list:
* You can't have loggy items queued in your working copy
All other working copy states are fully supported for upgrade for the step from 1.0-1.6 -> 1.7+
There are unsupported scenarios for the intermediate development formats, but there are no other limitations for the supported formats.
Bert
RE: rc1 is DOA. What now?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: woensdag 24 augustus 2011 9:50
> To: Markus Schaber
> Cc: dev@subversion.apache.org
> 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 don't care if we release rc1 anyway, reroll that as beta4 today or roll a
rc2 this week or accept this as a low impact fix for 1.7.0 without
restarting the soak. But rolling a known broken 1.7.0 because it is already
late is not good enough.
Maybe it is for the few developers who build and install their own binaries
side by side, but not for our real users.
Taking a few weeks to discuss this issue before making a decision is not
going to help...
Ivan and I already described this as a show stopper for our users and I'm
pretty sure Stefan would too.
(As noted by Markus I already have the fix in my daily snapshots which
currently follow 1.7.x)
Bert
Re: rc1 is DOA. What now?
Posted by Stefan Sperling <st...@elego.de>.
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.
AW: rc1 is DOA. What now?
Posted by Markus Schaber <m....@3s-software.com>.
Hi,
Von: Markus Schaber [mailto:m.schaber@3s-software.com]
> Von: Branko Čibej [mailto:brane@xbc.nu]
> > I wonder if it even makes sense to fix this case for upgrade. After
> > all, we could just tell users to unlock files before upgrading their
> > working copies.
>
> This would be rather unfortunate for our users - it would force working
> copy upgrade to be an online operation (because the workflow includes locks,
> so our software would have to do an unlock-upgrade-relock cycle.)
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.
A similar problem appears for most other users. All of them who update their software instead of installing the new version in parallel have the problem that they cannot unlock the working copies any more. This affects TortoiseSVN, AnkhSVN, VisualSVN, Subclipse, Subversive, or most users using the normal upgrade mechanism of their linux distro (very few of them ship both releases in parallel on a upgrade).
> Currently, this are only a few beta users, so we could live with that,
> however.
Just some more information about one of our use-case: Our CoDeSys IDE allows storing the project source archive on the PLC device. Now some service engineer needs to diagnose or fix some software on some customers PLC "in the field". She connects to the PLC, downloads the project archive (which includes the SVN working copy) to her Notebook, and now suddenly needs to "svn upgrade" to be able to continue working[1]. However, due to security reasons (StuxNet & co), she does not have connectivity to their svn repository at that site, so an offline working copy upgrade must be possible.
I admit that this is a rare use case (and currently only affects the few users of our first beta), but rather annoying (and expensive, a stopped PLC can cost millions) if it happens in production, say for svn 1.7 to 1.8 conversion.
However, it seems that Bert already forward-ported the patch to SharpSVN (Thanks!), so for us, it is a non-issue at the moment. I just wanted to illustrate some of the maybe more exotic, but real world usecases that most developers sitting at the desk in their office will never dream of.[2]
Best regards
Markus Schaber
[1] We still offer the workaround to disable svn support in that situation, but that means that structural modifications (additions, deletes, renames, moves, copies) are not synchronized to the working copy any more.
[2] I was such a clueless developer some time ago. If you ever want to change your view of software development, change your job to some company which also develops software, but in a completely different field, for completely different customers. You can re-use most of your skills, but have to apply them in an entirely changed world.
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
AW: rc1 is DOA. What now?
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Brane,
Von: Branko Čibej [mailto:brane@xbc.nu]
> I wonder if it even makes sense to fix this case for upgrade. After all,
> we could just tell users to unlock files before upgrading their working
> copies.
This would be rather unfortunate for our users - it would convert working copy upgrade to an online operation (because the workflow includes locks, so our software would have to do an unlock-upgrade-relock cycle.) Currently, this are only a few beta users, so we could live with that, however.
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: rc1 is DOA. What now?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/23/2011 05:57 PM, Hyrum K Wright wrote:
> On Tue, Aug 23, 2011 at 3:17 PM, Branko Čibej <br...@xbc.nu> wrote:
>> On 23.08.2011 21:21, Stefan Sperling wrote:
>>> On Tue, Aug 23, 2011 at 09:03:15PM +0200, Branko Čibej wrote:
>>>> I wonder if it even makes sense to fix this case for upgrade. After all,
>>>> we could just tell users to unlock files before upgrading their working
>>>> copies.
>>> Do you mean that it doesn't need to be fixed, ever?
>>> Or that this isn't a critical fix to have in the .0 release?
>>
>> It isn't critical to fix in the .0 release and not a good enough reason
>> to scrap RC1. I'd hesitate to call it a release blocker, after all,
>> there's a perfectly good workaround, and AFAIU not the only limitation
>> of the upgrader.
>
> Good points.
>
> At this point, I'm ready to run with the consensus, whatever that is.
Same here. My original post made the assumption that this problem was
already deemed a blocker (per Bert's vote and the IRC discussion I /join'd
in the middle of). But if it isn't and Bert will reverse his -1, let's move on.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: rc1 is DOA. What now?
Posted by Branko Čibej <br...@xbc.nu>.
On 24.08.2011 14:17, Julian Foad wrote:
> Hyrum K Wright wrote:
>> On Wed, Aug 24, 2011 at 6:07 AM, Julian Foad <ju...@wandisco.com> wrote:
>>> Having read the discussion elsethread, I now consider this a blocker and
>>> that also seems to be the consensus. So we can't release 1.7.0 with
>>> this bug; it has to be fixed. That in turn means the supposed 'RC1' is
>>> no longer an RC at all. [...]
>> So the grander feeling seems to be: scuttle rc1 (which already has the
>> votes for release)
> I interpreted Bert's "+1 as it passes regression tests but -1 to release
> as Subversion 1.7.0" the same as a "-1" vote for RC1, based on my
> understanding of the requirements for an RC.
>
> To make it plain, I hereby change my own RC1 vote to -1.
Looks like you guys are going to dither around a minor point so much
that the RC soak is going to last as long as the rest of the 1.7 cycle.
Are you quite sure you won't change your mind tomorrow? :)
-- Brane
Re: rc1 is DOA. What now?
Posted by Julian Foad <ju...@wandisco.com>.
Hyrum K Wright wrote:
> On Wed, Aug 24, 2011 at 6:07 AM, Julian Foad <ju...@wandisco.com> wrote:
> > Having read the discussion elsethread, I now consider this a blocker and
> > that also seems to be the consensus. So we can't release 1.7.0 with
> > this bug; it has to be fixed. That in turn means the supposed 'RC1' is
> > no longer an RC at all. [...]
>
> So the grander feeling seems to be: scuttle rc1 (which already has the
> votes for release)
I interpreted Bert's "+1 as it passes regression tests but -1 to release
as Subversion 1.7.0" the same as a "-1" vote for RC1, based on my
understanding of the requirements for an RC.
To make it plain, I hereby change my own RC1 vote to -1.
> and reroll an rc2. The fix for the 'upgrade with
> lock' issue is already on 1.7.x, so we can do this pretty much
> whenever we'd like. I'm inclined to do it tomorrow, following the
> normal pattern.
+1 to that.
- Julian
Re: rc1 is DOA. What now?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/24/2011 07:38 AM, Hyrum K Wright wrote:
> So the grander feeling seems to be: scuttle rc1 (which already has the
> votes for release) and reroll an rc2. The fix for the 'upgrade with
> lock' issue is already on 1.7.x, so we can do this pretty much
> whenever we'd like. I'm inclined to do it tomorrow, following the
> normal pattern.
+1.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: rc1 is DOA. What now?
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Wed, Aug 24, 2011 at 6:07 AM, Julian Foad <ju...@wandisco.com> wrote:
> On Tue, 2011-08-23, Hyrum K Wright wrote:
>> At this point, I'm ready to run with the consensus, whatever that is.
>
> Having read the discussion elsethread, I now consider this a blocker and
> that also seems to be the consensus. So we can't release 1.7.0 with
> this bug; it has to be fixed. That in turn means the supposed 'RC1' is
> no longer an RC at all. If the bug were found after RC release, the
> process would be different, but we have to draw the line somewhere and
> the moment of release is the obvious place to draw it.
>
> Fix it ASAP and release an RC that we believe is a true candidate at the
> moment of release.
>
> I think we handled this the right way. Although some of us wanted the
> RC to go ahead with the known bug, because we were not convinced it's
> serious enough, a developer's veto means it's not an RC. We must
> resolve that one way or the other before moving on, even if we don't
> like the delay.
So the grander feeling seems to be: scuttle rc1 (which already has the
votes for release) and reroll an rc2. The fix for the 'upgrade with
lock' issue is already on 1.7.x, so we can do this pretty much
whenever we'd like. I'm inclined to do it tomorrow, following the
normal pattern.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: rc1 is DOA. What now?
Posted by Julian Foad <ju...@wandisco.com>.
On Tue, 2011-08-23, Hyrum K Wright wrote:
> At this point, I'm ready to run with the consensus, whatever that is.
Having read the discussion elsethread, I now consider this a blocker and
that also seems to be the consensus. So we can't release 1.7.0 with
this bug; it has to be fixed. That in turn means the supposed 'RC1' is
no longer an RC at all. If the bug were found after RC release, the
process would be different, but we have to draw the line somewhere and
the moment of release is the obvious place to draw it.
Fix it ASAP and release an RC that we believe is a true candidate at the
moment of release.
I think we handled this the right way. Although some of us wanted the
RC to go ahead with the known bug, because we were not convinced it's
serious enough, a developer's veto means it's not an RC. We must
resolve that one way or the other before moving on, even if we don't
like the delay.
- Julian
Re: rc1 is DOA. What now?
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Aug 23, 2011 at 3:17 PM, Branko Čibej <br...@xbc.nu> wrote:
> On 23.08.2011 21:21, Stefan Sperling wrote:
>> On Tue, Aug 23, 2011 at 09:03:15PM +0200, Branko Čibej wrote:
>>> I wonder if it even makes sense to fix this case for upgrade. After all,
>>> we could just tell users to unlock files before upgrading their working
>>> copies.
>> Do you mean that it doesn't need to be fixed, ever?
>> Or that this isn't a critical fix to have in the .0 release?
>
> It isn't critical to fix in the .0 release and not a good enough reason
> to scrap RC1. I'd hesitate to call it a release blocker, after all,
> there's a perfectly good workaround, and AFAIU not the only limitation
> of the upgrader.
Good points.
At this point, I'm ready to run with the consensus, whatever that is.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: rc1 is DOA. What now?
Posted by Branko Čibej <br...@xbc.nu>.
On 23.08.2011 21:21, Stefan Sperling wrote:
> On Tue, Aug 23, 2011 at 09:03:15PM +0200, Branko Čibej wrote:
>> I wonder if it even makes sense to fix this case for upgrade. After all,
>> we could just tell users to unlock files before upgrading their working
>> copies.
> Do you mean that it doesn't need to be fixed, ever?
> Or that this isn't a critical fix to have in the .0 release?
It isn't critical to fix in the .0 release and not a good enough reason
to scrap RC1. I'd hesitate to call it a release blocker, after all,
there's a perfectly good workaround, and AFAIU not the only limitation
of the upgrader.
-- Brane
Re: rc1 is DOA. What now?
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Aug 23, 2011 at 09:03:15PM +0200, Branko Čibej wrote:
> I wonder if it even makes sense to fix this case for upgrade. After all,
> we could just tell users to unlock files before upgrading their working
> copies.
Do you mean that it doesn't need to be fixed, ever?
Or that this isn't a critical fix to have in the .0 release?
I can agree with the latter. But it should be fixed eventually.
It's tedious to unlock several files. Having existing locks survive
an upgrade is a lot better.
Re: rc1 is DOA. What now?
Posted by Branko Čibej <br...@xbc.nu>.
On 23.08.2011 20:07, Mark Phippard wrote:
> On Tue, Aug 23, 2011 at 1:52 PM, Hyrum K Wright
> <hyrum.wright@wandisco.com <ma...@wandisco.com>> wrote:
>
> In theory, we could end up shooting ourselves and our users in the
> feet by scuttling every RC between tag and release as issues become
> known. That's obviously a bit absurd, but it's worth asking where we
> draw that line?
>
>
> This is my problem too. During the RC cycles we are always so
> sensitive to these bugs, as if we are going to have a perfect release.
> We all know we could find issues in our tracker that are just as bad
> as these we have been discussing and we also know that once we release
> the software we do not treat these bugs with the same urgency. We try
> to react relatively quickly to bugs that could cause DoS or other
> exploits, as well as dataloss bugs but those are all pretty rare and
> not what we are talking about here. For normal bugs if this nature
> they would not show up in a fix release until enough similar fixes
> have been nominated and backported to warrant a new release.
>
> I am also fine with a re-roll though I would like to see us clear
> STATUS if we do. Meaning, let's remove the items that are not going
> to be in 1.7.x and get the votes for the rest. Otherwise, why not go
> with the RC we have (which already has the required votes for release).
I wonder if it even makes sense to fix this case for upgrade. After all,
we could just tell users to unlock files before upgrading their working
copies.
-- Brane
Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Aug 23, 2011 at 1:52 PM, Hyrum K Wright
<hy...@wandisco.com>wrote:
> In theory, we could end up shooting ourselves and our users in the
> feet by scuttling every RC between tag and release as issues become
> known. That's obviously a bit absurd, but it's worth asking where we
> draw that line?
>
This is my problem too. During the RC cycles we are always so sensitive to
these bugs, as if we are going to have a perfect release. We all know we
could find issues in our tracker that are just as bad as these we have been
discussing and we also know that once we release the software we do not
treat these bugs with the same urgency. We try to react relatively quickly
to bugs that could cause DoS or other exploits, as well as dataloss bugs but
those are all pretty rare and not what we are talking about here. For
normal bugs if this nature they would not show up in a fix release until
enough similar fixes have been nominated and backported to warrant a new
release.
I am also fine with a re-roll though I would like to see us clear STATUS if
we do. Meaning, let's remove the items that are not going to be in 1.7.x
and get the votes for the rest. Otherwise, why not go with the RC we have
(which already has the required votes for release).
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Aug 23, 2011 at 9:10 AM, C. Michael Pilato <cm...@collab.net> wrote:
> On 08/23/2011 08:17 AM, Bert Huijben wrote:
>>> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as
>>> Subversion 1.7.0
>>
>> Ok, make that a -1 to release as Subversion 1.7.0
>>
>> Subversion working copies that contain 'svn lock'-style locks can't be
>> upgraded by our current upgrade code. (We are mixing two sqlite handles
>> in the upgrade code and the code that inserts a lock checks if a node
>> exists using a db handle that can't look inside the transaction of the
>> other handle)
>>
>> I'm working on a fix and a regression test. (Should be fixed in a few
>> hours)
>
> In IRC, it has been essentially agreed that rc1 is DOA per the bug reported
> (and since fixed) above. The question then becomes, "What do we do with
> RC1?" I've seen these suggestions:
>
> (1) Keep on truckin'. Release it as-is but with a note saying "By the way,
> this won't be the final release candidate.
>
> (2) Re-roll the thing with exactly the same content, and from the same
> magic revision, except with the version tags reading "beta 4" instead of
> "release candidate 1".
>
> (3) Dump the re-release, and focus on a "soon" rc2 instead.
>
> I'd like to register my preference for Option #3
>
> Option #1 -- releasing a release candidate that's not a candidate for
> release -- just doesn't make any sense to me.
>
> Option #2 at least clears up the status of the release to better reflect
> what we know about its lifetime, but I fear we will feel obligated to put
> some "space" between this beta4 and our next real release candidate. This
> "space" would further delay the soak period for the release.
>
> Option #3 doesn't have either of these problems, and -- if we scheduled it
> for this Wednesday or Thursday -- gives us a little more time to address
> Bert's concerns (mentioned elsethread) that we haven't done proper justice
> to the STATUS backport review process. [ I think that's really just secret
> code for "Hey, nobody voted for my stuff!", but ... ;-) ]
I'm fine with #3 happening within the next couple of days.
<aside>
What's interesting here is that this conundrum was effectively caused
by the time between tag-and-release. If we tagged rc1 and tested,
signed, and released it within 24-hours, we wouldn't have known about
the lock problem, and the soak would have started. Whether the lock
problem is enough to warrant a re-soak is debatable, but the general
events may happen again.
In theory, we could end up shooting ourselves and our users in the
feet by scuttling every RC between tag and release as issues become
known. That's obviously a bit absurd, but it's worth asking where we
draw that line?
</aside>
> My goals are simple: I seek to minimize the administrative overhead we
> inflict on ourselves, minimize the number of publicized false starts our
> user base sees, and minimize further unnecessary delay to the release cycle.
> And maximize shareholder value! Oh, and have a pony! And cake ... that I
> get to eat, too!!
Don't forget our synergies!
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Aug 23, 2011 at 10:10 AM, C. Michael Pilato <cm...@collab.net>wrote:
> On 08/23/2011 08:17 AM, Bert Huijben wrote:
> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as
> >> Subversion 1.7.0
> >
> > Ok, make that a -1 to release as Subversion 1.7.0
> >
> > Subversion working copies that contain 'svn lock'-style locks can't be
> > upgraded by our current upgrade code. (We are mixing two sqlite handles
> > in the upgrade code and the code that inserts a lock checks if a node
> > exists using a db handle that can't look inside the transaction of the
> > other handle)
> >
> > I'm working on a fix and a regression test. (Should be fixed in a few
> > hours)
>
> In IRC, it has been essentially agreed that rc1 is DOA per the bug reported
> (and since fixed) above. The question then becomes, "What do we do with
> RC1?" I've seen these suggestions:
>
> (1) Keep on truckin'. Release it as-is but with a note saying "By the
> way,
> this won't be the final release candidate.
>
> (2) Re-roll the thing with exactly the same content, and from the same
> magic revision, except with the version tags reading "beta 4" instead of
> "release candidate 1".
>
> (3) Dump the re-release, and focus on a "soon" rc2 instead.
>
> I'd like to register my preference for Option #3
>
Of these options, I would also prefer option #3. That said, I am not sure
if I agree that this is not a legitimate RC. There are some known bugs. So
what? Was any data lost, were puppies harmed? Suppose we roll an RC2 now.
You do not think over the 4 week cycle there will not be another bug that
surfaces? We already had known bug fixes in STATUS when we rolled the
release candidate.
I guarantee if this upgrade bug surfaced after 1.7.0 we would take our
normal sweet time in rolling a 1.7.1. It is not like we would drop
everything and push out an immediate release to fix this. So why pull the
emergency brake and stop the RC?
If people really want this bug fixed in the final version than vote for it
in STATUS so that Hyrum can merge it into the final release that is issued.
This is not a fix that requires an API or other compatibility concerning
change.
Maybe this means I prefer your option #1 and just do not agree with how the
situation is being portrayed.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Aug 23, 2011 at 9:53 AM, Bob Archer <Bo...@amsi.com> wrote:
>> On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer <Bo...@amsi.com>
>> wrote:
>> >> On 08/23/2011 08:17 AM, Bert Huijben wrote:
>> >> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release
>> >> >> +as
>> >> >> Subversion 1.7.0
>> >> >
>> >> > Ok, make that a -1 to release as Subversion 1.7.0
>> >> >
>> >> > Subversion working copies that contain 'svn lock'-style locks can't
>> >> > be upgraded by our current upgrade code. (We are mixing two sqlite
>> >> > handles in the upgrade code and the code that inserts a lock checks
>> >> > if a node exists using a db handle that can't look inside the
>> >> > transaction of the other handle)
>> >> >
>> >> > I'm working on a fix and a regression test. (Should be fixed in a
>> >> > few
>> >> > hours)
>> >>
>> >> In IRC, it has been essentially agreed that rc1 is DOA per the bug
>> >> reported (and since fixed) above. The question then becomes, "What
>> >> do we do with RC1?" I've seen these suggestions:
>> >>
>> >> (1) Keep on truckin'. Release it as-is but with a note saying "By
>> >> the way, this won't be the final release candidate.
>> >>
>> >> (2) Re-roll the thing with exactly the same content, and from the
>> >> same magic revision, except with the version tags reading "beta 4"
>> >> instead of "release candidate 1".
>> >>
>> >> (3) Dump the re-release, and focus on a "soon" rc2 instead.
>> >>
>> >> I'd like to register my preference for Option #3
>> >>
>> >> Option #1 -- releasing a release candidate that's not a candidate for
>> >> release -- just doesn't make any sense to me.
>> >>
>> >> Option #2 at least clears up the status of the release to better
>> >> reflect what we know about its lifetime, but I fear we will feel
>> >> obligated to put some "space" between this beta4 and our next real
>> >> release candidate. This "space" would further delay the soak period for
>> the release.
>> >>
>> >> Option #3 doesn't have either of these problems, and -- if we
>> >> scheduled it for this Wednesday or Thursday -- gives us a little more
>> >> time to address Bert's concerns (mentioned elsethread) that we
>> >> haven't done proper justice to the STATUS backport review process. [
>> >> I think that's really just secret code for "Hey, nobody voted for my
>> >> stuff!", but ... ;-) ]
>> >
>> > I'm not sure why you guys would version a "release" and then skip it. The
>> first release candidate that is "released" should be called RC1, no matter
>> what revision it is built from. Your gonna confuse people.
>>
>> We're going to confuse people if we *don't* skip RC1. Version numbers are
>> cheap, and we've already labelled something (in both the repository and our
>> own craniums) as RC1. If we create *another* RC1, every time somebody
>> references an "RC1" we have to ask "which one?"
>> That way lies madness....
>>
>> -Hyrum
>
> At my shop we don't tag our releases until they are approved for release. So, if we are working on 1.0Beta1 and find a problem we don't just make changes and call it Beta2 we fix the pre-release issues and build the beta from a later revision. Once it is approved to release we tag it 1.0Beta1 and release it.
There isn't a single best way that works for all folks. Your strategy
works for you, and that's great.
In the past, we did recycle version numbers, even on release
candidates, and it proved troublesome, so we just decided not to.
> Funny, I'm not mad yet... or am I?
"We're all a little mad here." :)
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Aug 23, 2011 at 10:53 AM, Bob Archer <Bo...@amsi.com> wrote:
> > On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer <Bo...@amsi.com>
> > wrote:
> > >> On 08/23/2011 08:17 AM, Bert Huijben wrote:
> > >> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release
> > >> >> +as
> > >> >> Subversion 1.7.0
> > >> >
> > >> > Ok, make that a -1 to release as Subversion 1.7.0
> > >> >
> > >> > Subversion working copies that contain 'svn lock'-style locks can't
> > >> > be upgraded by our current upgrade code. (We are mixing two sqlite
> > >> > handles in the upgrade code and the code that inserts a lock checks
> > >> > if a node exists using a db handle that can't look inside the
> > >> > transaction of the other handle)
> > >> >
> > >> > I'm working on a fix and a regression test. (Should be fixed in a
> > >> > few
> > >> > hours)
> > >>
> > >> In IRC, it has been essentially agreed that rc1 is DOA per the bug
> > >> reported (and since fixed) above. The question then becomes, "What
> > >> do we do with RC1?" I've seen these suggestions:
> > >>
> > >> (1) Keep on truckin'. Release it as-is but with a note saying "By
> > >> the way, this won't be the final release candidate.
> > >>
> > >> (2) Re-roll the thing with exactly the same content, and from the
> > >> same magic revision, except with the version tags reading "beta 4"
> > >> instead of "release candidate 1".
> > >>
> > >> (3) Dump the re-release, and focus on a "soon" rc2 instead.
> > >>
> > >> I'd like to register my preference for Option #3
> > >>
> > >> Option #1 -- releasing a release candidate that's not a candidate for
> > >> release -- just doesn't make any sense to me.
> > >>
> > >> Option #2 at least clears up the status of the release to better
> > >> reflect what we know about its lifetime, but I fear we will feel
> > >> obligated to put some "space" between this beta4 and our next real
> > >> release candidate. This "space" would further delay the soak period
> for
> > the release.
> > >>
> > >> Option #3 doesn't have either of these problems, and -- if we
> > >> scheduled it for this Wednesday or Thursday -- gives us a little more
> > >> time to address Bert's concerns (mentioned elsethread) that we
> > >> haven't done proper justice to the STATUS backport review process. [
> > >> I think that's really just secret code for "Hey, nobody voted for my
> > >> stuff!", but ... ;-) ]
> > >
> > > I'm not sure why you guys would version a "release" and then skip it.
> The
> > first release candidate that is "released" should be called RC1, no
> matter
> > what revision it is built from. Your gonna confuse people.
> >
> > We're going to confuse people if we *don't* skip RC1. Version numbers
> are
> > cheap, and we've already labelled something (in both the repository and
> our
> > own craniums) as RC1. If we create *another* RC1, every time somebody
> > references an "RC1" we have to ask "which one?"
> > That way lies madness....
> >
> > -Hyrum
>
> At my shop we don't tag our releases until they are approved for release.
> So, if we are working on 1.0Beta1 and find a problem we don't just make
> changes and call it Beta2 we fix the pre-release issues and build the beta
> from a later revision. Once it is approved to release we tag it 1.0Beta1 and
> release it.
>
> Funny, I'm not mad yet... or am I?
>
>
Do you announce the availability of these "releases" on public mailing lists
and invite people to look at them before they are approved?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)
Posted by Bob Archer <Bo...@amsi.com>.
> On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer <Bo...@amsi.com>
> wrote:
> >> On 08/23/2011 08:17 AM, Bert Huijben wrote:
> >> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release
> >> >> +as
> >> >> Subversion 1.7.0
> >> >
> >> > Ok, make that a -1 to release as Subversion 1.7.0
> >> >
> >> > Subversion working copies that contain 'svn lock'-style locks can't
> >> > be upgraded by our current upgrade code. (We are mixing two sqlite
> >> > handles in the upgrade code and the code that inserts a lock checks
> >> > if a node exists using a db handle that can't look inside the
> >> > transaction of the other handle)
> >> >
> >> > I'm working on a fix and a regression test. (Should be fixed in a
> >> > few
> >> > hours)
> >>
> >> In IRC, it has been essentially agreed that rc1 is DOA per the bug
> >> reported (and since fixed) above. The question then becomes, "What
> >> do we do with RC1?" I've seen these suggestions:
> >>
> >> (1) Keep on truckin'. Release it as-is but with a note saying "By
> >> the way, this won't be the final release candidate.
> >>
> >> (2) Re-roll the thing with exactly the same content, and from the
> >> same magic revision, except with the version tags reading "beta 4"
> >> instead of "release candidate 1".
> >>
> >> (3) Dump the re-release, and focus on a "soon" rc2 instead.
> >>
> >> I'd like to register my preference for Option #3
> >>
> >> Option #1 -- releasing a release candidate that's not a candidate for
> >> release -- just doesn't make any sense to me.
> >>
> >> Option #2 at least clears up the status of the release to better
> >> reflect what we know about its lifetime, but I fear we will feel
> >> obligated to put some "space" between this beta4 and our next real
> >> release candidate. This "space" would further delay the soak period for
> the release.
> >>
> >> Option #3 doesn't have either of these problems, and -- if we
> >> scheduled it for this Wednesday or Thursday -- gives us a little more
> >> time to address Bert's concerns (mentioned elsethread) that we
> >> haven't done proper justice to the STATUS backport review process. [
> >> I think that's really just secret code for "Hey, nobody voted for my
> >> stuff!", but ... ;-) ]
> >
> > I'm not sure why you guys would version a "release" and then skip it. The
> first release candidate that is "released" should be called RC1, no matter
> what revision it is built from. Your gonna confuse people.
>
> We're going to confuse people if we *don't* skip RC1. Version numbers are
> cheap, and we've already labelled something (in both the repository and our
> own craniums) as RC1. If we create *another* RC1, every time somebody
> references an "RC1" we have to ask "which one?"
> That way lies madness....
>
> -Hyrum
At my shop we don't tag our releases until they are approved for release. So, if we are working on 1.0Beta1 and find a problem we don't just make changes and call it Beta2 we fix the pre-release issues and build the beta from a later revision. Once it is approved to release we tag it 1.0Beta1 and release it.
Funny, I'm not mad yet... or am I?
BOb
Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer <Bo...@amsi.com> wrote:
>> On 08/23/2011 08:17 AM, Bert Huijben wrote:
>> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as
>> >> Subversion 1.7.0
>> >
>> > Ok, make that a -1 to release as Subversion 1.7.0
>> >
>> > Subversion working copies that contain 'svn lock'-style locks can't be
>> > upgraded by our current upgrade code. (We are mixing two sqlite
>> > handles in the upgrade code and the code that inserts a lock checks if
>> > a node exists using a db handle that can't look inside the transaction
>> > of the other handle)
>> >
>> > I'm working on a fix and a regression test. (Should be fixed in a few
>> > hours)
>>
>> In IRC, it has been essentially agreed that rc1 is DOA per the bug reported
>> (and since fixed) above. The question then becomes, "What do we do with
>> RC1?" I've seen these suggestions:
>>
>> (1) Keep on truckin'. Release it as-is but with a note saying "By the way, this
>> won't be the final release candidate.
>>
>> (2) Re-roll the thing with exactly the same content, and from the same magic
>> revision, except with the version tags reading "beta 4" instead of "release
>> candidate 1".
>>
>> (3) Dump the re-release, and focus on a "soon" rc2 instead.
>>
>> I'd like to register my preference for Option #3
>>
>> Option #1 -- releasing a release candidate that's not a candidate for release --
>> just doesn't make any sense to me.
>>
>> Option #2 at least clears up the status of the release to better reflect what
>> we know about its lifetime, but I fear we will feel obligated to put some
>> "space" between this beta4 and our next real release candidate. This
>> "space" would further delay the soak period for the release.
>>
>> Option #3 doesn't have either of these problems, and -- if we scheduled it
>> for this Wednesday or Thursday -- gives us a little more time to address Bert's
>> concerns (mentioned elsethread) that we haven't done proper justice to the
>> STATUS backport review process. [ I think that's really just secret code for
>> "Hey, nobody voted for my stuff!", but ... ;-) ]
>
> I'm not sure why you guys would version a "release" and then skip it. The first release candidate that is "released" should be called RC1, no matter what revision it is built from. Your gonna confuse people.
We're going to confuse people if we *don't* skip RC1. Version numbers
are cheap, and we've already labelled something (in both the
repository and our own craniums) as RC1. If we create *another* RC1,
every time somebody references an "RC1" we have to ask "which one?"
That way lies madness....
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
RE: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing /
signing)
Posted by Bob Archer <Bo...@amsi.com>.
> On 08/23/2011 08:17 AM, Bert Huijben wrote:
> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as
> >> Subversion 1.7.0
> >
> > Ok, make that a -1 to release as Subversion 1.7.0
> >
> > Subversion working copies that contain 'svn lock'-style locks can't be
> > upgraded by our current upgrade code. (We are mixing two sqlite
> > handles in the upgrade code and the code that inserts a lock checks if
> > a node exists using a db handle that can't look inside the transaction
> > of the other handle)
> >
> > I'm working on a fix and a regression test. (Should be fixed in a few
> > hours)
>
> In IRC, it has been essentially agreed that rc1 is DOA per the bug reported
> (and since fixed) above. The question then becomes, "What do we do with
> RC1?" I've seen these suggestions:
>
> (1) Keep on truckin'. Release it as-is but with a note saying "By the way, this
> won't be the final release candidate.
>
> (2) Re-roll the thing with exactly the same content, and from the same magic
> revision, except with the version tags reading "beta 4" instead of "release
> candidate 1".
>
> (3) Dump the re-release, and focus on a "soon" rc2 instead.
>
> I'd like to register my preference for Option #3
>
> Option #1 -- releasing a release candidate that's not a candidate for release --
> just doesn't make any sense to me.
>
> Option #2 at least clears up the status of the release to better reflect what
> we know about its lifetime, but I fear we will feel obligated to put some
> "space" between this beta4 and our next real release candidate. This
> "space" would further delay the soak period for the release.
>
> Option #3 doesn't have either of these problems, and -- if we scheduled it
> for this Wednesday or Thursday -- gives us a little more time to address Bert's
> concerns (mentioned elsethread) that we haven't done proper justice to the
> STATUS backport review process. [ I think that's really just secret code for
> "Hey, nobody voted for my stuff!", but ... ;-) ]
I'm not sure why you guys would version a "release" and then skip it. The first release candidate that is "released" should be called RC1, no matter what revision it is built from. Your gonna confuse people.
BOb
>
> My goals are simple: I seek to minimize the administrative overhead we
> inflict on ourselves, minimize the number of publicized false starts our user
> base sees, and minimize further unnecessary delay to the release cycle.
> And maximize shareholder value! Oh, and have a pony! And cake ... that I
> get to eat, too!!
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
Re: rc1 is DOA. What now?
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <da...@elego.de> writes:
> C. Michael Pilato wrote on Tue, Aug 23, 2011 at 10:10:28 -0400:
>> Option #1 -- releasing a release candidate that's not a candidate for
>> release -- just doesn't make any sense to me.
>
> There are still items on
> http://subversion.apache.org/roadmap#release-status that don't have
> a green light next to them. Shouldn't, by your logic, all of them be
> green before an RC is rolled?
It's possible that release-status will go green without requring and
release critical changes to the tarball. "Don't release an -rc that is
know to be broken" and "don't release an -rc that may need changes" are
different rules.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing /
signing)
Posted by Daniel Shahaf <da...@elego.de>.
C. Michael Pilato wrote on Tue, Aug 23, 2011 at 10:10:28 -0400:
> Option #1 -- releasing a release candidate that's not a candidate for
> release -- just doesn't make any sense to me.
There are still items on
http://subversion.apache.org/roadmap#release-status that don't have
a green light next to them. Shouldn't, by your logic, all of them be
green before an RC is rolled?
(Some of the items have been done --- eg, serf is resolved, and I remember
Paul and Julian reviewing XFailing tests and APIs; but I don't know where
"API Profiling" and "Update CHANGES" stand.)
rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/23/2011 08:17 AM, Bert Huijben wrote:
>> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as
>> Subversion 1.7.0
>
> Ok, make that a -1 to release as Subversion 1.7.0
>
> Subversion working copies that contain 'svn lock'-style locks can't be
> upgraded by our current upgrade code. (We are mixing two sqlite handles
> in the upgrade code and the code that inserts a lock checks if a node
> exists using a db handle that can't look inside the transaction of the
> other handle)
>
> I'm working on a fix and a regression test. (Should be fixed in a few
> hours)
In IRC, it has been essentially agreed that rc1 is DOA per the bug reported
(and since fixed) above. The question then becomes, "What do we do with
RC1?" I've seen these suggestions:
(1) Keep on truckin'. Release it as-is but with a note saying "By the way,
this won't be the final release candidate.
(2) Re-roll the thing with exactly the same content, and from the same
magic revision, except with the version tags reading "beta 4" instead of
"release candidate 1".
(3) Dump the re-release, and focus on a "soon" rc2 instead.
I'd like to register my preference for Option #3
Option #1 -- releasing a release candidate that's not a candidate for
release -- just doesn't make any sense to me.
Option #2 at least clears up the status of the release to better reflect
what we know about its lifetime, but I fear we will feel obligated to put
some "space" between this beta4 and our next real release candidate. This
"space" would further delay the soak period for the release.
Option #3 doesn't have either of these problems, and -- if we scheduled it
for this Wednesday or Thursday -- gives us a little more time to address
Bert's concerns (mentioned elsethread) that we haven't done proper justice
to the STATUS backport review process. [ I think that's really just secret
code for "Hey, nobody voted for my stuff!", but ... ;-) ]
My goals are simple: I seek to minimize the administrative overhead we
inflict on ourselves, minimize the number of publicized false starts our
user base sees, and minimize further unnecessary delay to the release cycle.
And maximize shareholder value! Oh, and have a pony! And cake ... that I
get to eat, too!!
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: 1.7.0-rc1 up for testing / signing
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: dinsdag 23 augustus 2011 11:08
> To: 'Hyrum K Wright'; 'Subversion Development'
> Subject: RE: 1.7.0-rc1 up for testing / signing
>
>
>
> > -----Original Message-----
> > From: Hyrum K Wright [mailto:hyrum.wright@wandisco.com]
> > Sent: vrijdag 19 augustus 2011 20:24
> > To: Subversion Development
> > Subject: 1.7.0-rc1 up for testing / signing
> >
> > Here it is: the first Release Candidate for Subversion 1.7.0. You can
> > fetch the proposed tarballs from here:
> > http://people.apache.org/~hwright/svn/1.7.0-rc1/
> >
> > The magic rev is r1159696; please post signatures at the normal location:
> > http://work.hyrumwright.org/pub/svn/collect_sigs.py
> >
> > This is a release candidate, meaning if all goes well it (or something
> > very much like it) will become the final release. Please test this as
> > if it were the final release, understanding that there will be bugs in
> > any software we ship. <insert lecture about perfect being enemy of
> > the good here>
>
> +1 to release as 1.7.0-RC1 as all tests pass for me.
> -0 to release as Subversion 1.7.0
Ok, make that a -1 to release as Subversion 1.7.0
Subversion working copies that contain 'svn lock'-style locks can't be upgraded by our current upgrade code.
(We are mixing two sqlite handles in the upgrade code and the code that inserts a lock checks if a node exists using a db handle that can't look inside the transaction of the other handle)
I'm working on a fix and a regression test. (Should be fixed in a few hours)
Thanks to Markus Schaber for providing this testcase.
Bert
Re: 1.7.0-rc1 up for testing / signing
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Aug 23, 2011 at 4:07 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum.wright@wandisco.com]
>> Sent: vrijdag 19 augustus 2011 20:24
>> To: Subversion Development
>> Subject: 1.7.0-rc1 up for testing / signing
>>
>> Here it is: the first Release Candidate for Subversion 1.7.0. You can
>> fetch the proposed tarballs from here:
>> http://people.apache.org/~hwright/svn/1.7.0-rc1/
>>
>> The magic rev is r1159696; please post signatures at the normal location:
>> http://work.hyrumwright.org/pub/svn/collect_sigs.py
>>
>> This is a release candidate, meaning if all goes well it (or something
>> very much like it) will become the final release. Please test this as
>> if it were the final release, understanding that there will be bugs in
>> any software we ship. <insert lecture about perfect being enemy of
>> the good here>
>
> +1 to release as 1.7.0-RC1 as all tests pass for me.
> -0 to release as Subversion 1.7.0
>
> I don't think we tried hard enough to clear STATUS to make this a valid 1.7.0 for me.
> There are still a few items that should have been resolved.
> The only reason to make this a 1.7.0 would be that we assume that all users just wait until 1.7.1 anyway, and I don't want to encourage users to do that.
To paraphrase a private mail I sent around yesterday: "We encourage
people that are testing it to do so as if it was the final release.
They'll either be testing it as rc1 or as the final, and the former is
preferable to both us and them."
Of course, if we *do* find and fix bugs, 1.7.0-rc1 doesn't have to
become the final release; we can fix the bugs prior to that happening.
In any case the release plan (and my plan) is that we roll a final RC
a few days before the final release to pick up any remaining bug fixes
which have been merged to the branch. I'm not even opposed to doing
an rc2 in a couple of weeks at the half-way point of the soak.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
RE: 1.7.0-rc1 up for testing / signing
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum.wright@wandisco.com]
> Sent: vrijdag 19 augustus 2011 20:24
> To: Subversion Development
> Subject: 1.7.0-rc1 up for testing / signing
>
> Here it is: the first Release Candidate for Subversion 1.7.0. You can
> fetch the proposed tarballs from here:
> http://people.apache.org/~hwright/svn/1.7.0-rc1/
>
> The magic rev is r1159696; please post signatures at the normal location:
> http://work.hyrumwright.org/pub/svn/collect_sigs.py
>
> This is a release candidate, meaning if all goes well it (or something
> very much like it) will become the final release. Please test this as
> if it were the final release, understanding that there will be bugs in
> any software we ship. <insert lecture about perfect being enemy of
> the good here>
+1 to release as 1.7.0-RC1 as all tests pass for me.
-0 to release as Subversion 1.7.0
I don't think we tried hard enough to clear STATUS to make this a valid 1.7.0 for me.
There are still a few items that should have been resolved.
The only reason to make this a 1.7.0 would be that we assume that all users just wait until 1.7.1 anyway, and I don't want to encourage users to do that.
Visual Studio 2010 SP1 x86
Windows 7 Business X64
[fsfs | bdb] x [ra_local | ra_svn | ra_neon | ra_serf] + JavaHL + SharpSvn
Apr 1.4.5+r960671
Apr-Util 1.3.12
Apr-Iconv 1.2.11
BDB 4.4.20
Cyrus Sasl 2.1.23
GetText 0.17
Httpd 2.2.19
Junit 4.8.1
Neon 0.29.6
OpenSSL 1.0.0d
Serf 1.0.0
SQLite 3.7.7.1
ZLib 1.2.5
In the last few days I had a few bug reports for SharpSvn from users testing against 1.7. Those have been resolved without requiring additional patches to Subversion.
Bert
Re: 1.7.0-rc1 up for testing / signing
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Aug 23, 2011 at 2:51 AM, Hyrum K Wright
<hy...@wandisco.com> wrote:
> FYI: by my count we're still lacking one Windows sig.
>
> Ivan, I know you tested the release but had some concerns, which folks
> have discussed. If you're comfortable with the resolution, would you
> mind sending over signatures?
>
> (One of these days Johan will get back off holiday, and we'll have
> another Windows signer. :) )
Thanks for the hint :-).
I'm sort of back from holiday, slowly getting worked in again. I'd
like to test the release, but currently I'm having some trouble with
my build environment, so it'll take me some more time. I'm currently
not sure how much time, so Ivan will probably beat me to it :-).
--
Johan
Re: 1.7.0-rc1 up for testing / signing
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Tue, Aug 23, 2011 at 04:51, Hyrum K Wright <hy...@wandisco.com> wrote:
> FYI: by my count we're still lacking one Windows sig.
>
> Ivan, I know you tested the release but had some concerns, which folks
> have discussed. If you're comfortable with the resolution, would you
> mind sending over signatures?
>
Hyrum,
I'm going to provide signatures for 1.7.0-rc1 when I'm come to office today.
--
Ivan Zhakov
Re: 1.7.0-rc1 up for testing / signing
Posted by Hyrum K Wright <hy...@wandisco.com>.
FYI: by my count we're still lacking one Windows sig.
Ivan, I know you tested the release but had some concerns, which folks
have discussed. If you're comfortable with the resolution, would you
mind sending over signatures?
(One of these days Johan will get back off holiday, and we'll have
another Windows signer. :) )
Thanks,
-Hyrum
On Fri, Aug 19, 2011 at 1:24 PM, Hyrum K Wright
<hy...@wandisco.com> wrote:
> Here it is: the first Release Candidate for Subversion 1.7.0. You can
> fetch the proposed tarballs from here:
> http://people.apache.org/~hwright/svn/1.7.0-rc1/
>
> The magic rev is r1159696; please post signatures at the normal location:
> http://work.hyrumwright.org/pub/svn/collect_sigs.py
>
> This is a release candidate, meaning if all goes well it (or something
> very much like it) will become the final release. Please test this as
> if it were the final release, understanding that there will be bugs in
> any software we ship. <insert lecture about perfect being enemy of
> the good here>
>
> To all distributors and binary packagers: This isn't the final
> release. It *won't* be the final release for a few weeks yet, so
> please don't ship it as such. In any case, don't distribute any
> releases based upon these tarballs until we complete our signature
> gathering process and officially announce the release.
>
> -Hyrum
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: 1.7.0-rc1 up for testing / signing
Posted by Philip Martin <ph...@wandisco.com>.
Summary:
+1 to release
Platform:
Linux (Debian/squeeze)
Tested:
(local, svn, svn+sasl, serf, neon) x (fsfs, fsfs/pack/shard, bdb)
(serf/v1, neon/v1) x (fsfs, bdb)
swig-pl, swig-py, swig-rb
javahl x (fsfs, bdb)
Results:
All tests PASS
Local dependencies:
apache2-threaded-dev : 2.2.16-6+squeeze1
libapr1-dev : 1.4.2-6+squeeze3
libaprutil1-dev : 1.3.9+dfsg-5
libdb4.8-dev : 4.8.30-2
libneon27-dev : 0.29.3-3
libsasl2-dev : 2.1.23.dfsg1-7
libsqlite3-dev : 3.7.3-1
perl : 5.10.1-17squeeze2
python2.6-dev : 2.6.6-8+b1
ruby1.8-dev : 1.8.7.302-2squeeze1
openjdk-6-jdk : 6b18-1.8.7-2~squeeze1
serf : trunk@1557
subversion-1.7.0-rc1.tar.bz2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAABCAAGBQJOUm7xAAoJEHbXiOHtGlmcBEsIAJvMcn9f/ReX4X6hHOC0Q9wH
TtsVws9ppGDlzhMGCzM7Fx5mnovJtn28867wjDZgekgs231dq1E4weoDQO2xxiAn
/V4SH+QfcjVb9JSOaXdyBiG31iMdjN6c5bXZK51vNqbYa5XBwnOdKiJSffAjp1N1
Naf43d9m1GQohkaJvVfDBt1w/k/Na2Zs4n59rUD/QeD7twBZdNa3tCfugQcTdCMl
T7UfQMb60rzBHQ1Xqma0BjMOHMZTO+MADa84YsGu57tQTm2NgdpybXh/+iAGachC
zghUjBLqHsEYZl44+XZcskXozOISO/X//5ovEtDpbAD5ZH01KD5W/Qkmea4skVs=
=KMmq
-----END PGP SIGNATURE-----
subversion-1.7.0-rc1.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAABCAAGBQJOUm8KAAoJEHbXiOHtGlmc4BAH/3BuA/+Z5/nzax+wa0a604Ze
mTYuvcc505wMEbvLKM1UF+CkWLpUB7OIptINSnmFskV4ivftFiPIkG4JQsQQIigm
6EovFkW4qdRvbWRR9Xmehyb/+6MnEK5RAiTRRSBo8YraCaYPvZEyPL9ywmhu3YIn
tam2jtt2t9ANXZav47Yno1lltLh7hT428DetLajB/FOL0gjpJviot9lVelpjFxqn
i7m2HgfKdyfYVCnZqOOxeH9kJasrhq8Xe+f38x0jf1T8/26D4yEBFGiHCu4TrlZq
cscZyiW81hbIOwJo48tnrYs60lGIVfDNBoNd9SAYts80WGNFDT+yWldXXVRtKWM=
=TdZV
-----END PGP SIGNATURE-----
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: 1.7.0-rc1 up for testing / signing
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/19/2011 02:24 PM, Hyrum K Wright wrote:
> Here it is: the first Release Candidate for Subversion 1.7.0. You can
> fetch the proposed tarballs from here:
> http://people.apache.org/~hwright/svn/1.7.0-rc1/
Summary:
+1 to release.
Platform:
Ubuntu 10.04.3 (lucid) Linux (x86)
Python 2.6.5
Perl 5.10.1
Ruby 1.8.7
Java 1.6.0
Tested:
(local, svn, neon, serf) x (bdb, fsfs) + \
py + py + pl + rb + javahl + ctypes-python
Results:
All tests pass.
MD5 Checksums:
d52fef4b57947cd98ee504cf30fe371e subversion-1.7.0-rc1.tar.gz
765b95f63414e74a99bf3760496848ef subversion-1.7.0-rc1.tar.bz2
GPG Signatures (left-aligned because Hyrum likes it that way):
::: subversion-1.7.0-rc1.tar.gz :::
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk5OrOgACgkQokEGqRcG/W77LwCghfLubwXibZfMIMeBTIEzf3Wf
DOUAoLaPpRaCP6pjwm06WW73I0uEcHR0
=ud9i
-----END PGP SIGNATURE-----
::: subversion-1.7.0-rc1.tar.bz2 :::
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk5OrOoACgkQokEGqRcG/W5AuACfWNcc+imI+69OZdBm9ZToKIR7
pPAAnRabwX1npmdQh4LdqqVWiOsPDHuy
=4piv
-----END PGP SIGNATURE-----
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.7.0-rc1 up for testing / signing
Posted by Julian Foad <ju...@wandisco.com>.
On Fri, 2011-08-19, Hyrum K Wright wrote:
> Here it is: the first Release Candidate for Subversion 1.7.0. [...]
Summary:
+1 to release (Unix).
My two signatures were successfully collected by your script.
Tested:
[ bdb | fsfs ] x [ ra_local | ra_svn | ra_neon | ra_serf ]
swig-py
swig-pl
swig-rb
ctypes-python
(I also built javahl, but couldn't get its tests to run. I'm assuming
that's a local problem. It's not a new problem.)
Results:
All tests passed.
Environment:
OS/Platform:
Ubuntu 10.10, 2.6.35-30-generic i686 GNU/Linux
Using no in-tree build of dependencies.
Using Ubuntu distribution-supplied packages:
libapr1 1.4.2-3ubuntu1
libaprutil1 1.3.9+dfsg-3build1
libdb-dev 4.8
openssl 0.9.8o-1ubuntu4
perl 5.10.1-12ubuntu2
python 2.6.6-2ubuntu2
zlib1g 1:1.2.3.4.dfsg-3ubuntu1
ruby 1.8.7
neon 0.29.3
Using self-built packages:
serf 0.7.2
Signatures:
::: subversion-1.7.0-rc1.tar.bz2 :::
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk5SDa8ACgkQNR8z5DU+JbzlJQCeMFOyzYp0ahZhG0mmeUCoUChq
FcoAnjQOb8fbnfxu54ve+8LG8ww171x4
=04JM
-----END PGP SIGNATURE-----
::: subversion-1.7.0-rc1.tar.gz :::
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk5SDa8ACgkQNR8z5DU+JbwkFgCfZPl/Rj+edUgwnFPp2xp3apZw
xX8AoJkh4vgApPn9h4gfDhYriio0JZpK
=m+5r
-----END PGP SIGNATURE-----
- Julian
Re: 1.7.0-rc1 up for testing / signing
Posted by Philip Martin <ph...@wandisco.com>.
Ivan Zhakov <iv...@visualsvn.com> writes:
> EXPECTED STDERR (regexp):
> svn: warning: W195007: URL
> 'svn://localhost//svn-test-work/local_tmp/repos/A' refers to a directory
> .*
> ACTUAL STDERR:
> svn: warning: W195007: URL 'svn://localhost/svn-test-work/local_tmp/repos/A'
> refers to a directory
> svn: E200009: Could not cat all targets because some targets don't exist
> CWD:
I can reproduce that on my Linux box by running:
$ ./cat_tests.py --url=svn://localhost// 2
EXPECTED STDERR (regexp):
svn: warning: W195007: URL 'svn://localhost//svn-test-work/local_tmp/repos/A' refers to a directory
.*
ACTUAL STDERR:
svn: warning: W195007: URL 'svn://localhost/svn-test-work/local_tmp/repos/A' refers to a directory
../src-1.7/subversion/svn/cat-cmd.c:94: (apr_err=200009)
svn: E200009: Could not cat all targets because some targets don't exist
Note I use two trailing slashes on the URL parameter to get the FAIL,
it's a PASS with one slash or without a slash.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: 1.7.0-rc1 up for testing / signing
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Mon, Aug 22, 2011 at 19:44, Bert Huijben <be...@qqmail.nl> wrote:
> Hi,****
>
> ** **
>
> I can reproduce that our testsuite produces some commands with ‘//’ instead
> of ‘/’ when I pass ‘-u svn://localhost/’ instead of ‘–u svn://localhost’,
> but this doesn’t break the cat tests for me, as further commands seem to use
> the canonical url.****
>
> ** **
>
> My normal test line for testing svnserve is:****
>
> win-tests.py -p -d -f fsfs -u svn://localhost -c R: \Svn-2010\tests****
>
> ** **
>
> Hi Bert,
Thanks for information. I'm running test suite with fixed url and it seems
to pass.
--
Ivan Zhakov
RE: 1.7.0-rc1 up for testing / signing
Posted by Bert Huijben <be...@qqmail.nl>.
Hi,
I can reproduce that our testsuite produces some commands with ‘//’ instead of ‘/’ when I pass ‘-u svn://localhost/’ instead of ‘–u svn://localhost’, but this doesn’t break the cat tests for me, as further commands seem to use the canonical url.
My normal test line for testing svnserve is:
win-tests.py -p -d -f fsfs -u svn://localhost -c R: \Svn-2010\tests
Bert
From: Ivan Zhakov [mailto:ivan@visualsvn.com]
Sent: maandag 22 augustus 2011 17:34
To: Hyrum K Wright
Cc: Subversion Development
Subject: Re: 1.7.0-rc1 up for testing / signing
On Fri, Aug 19, 2011 at 22:24, Hyrum K Wright <hy...@wandisco.com> wrote:
> Here it is: the first Release Candidate for Subversion 1.7.0. You can
> fetch the proposed tarballs from here:
> http://people.apache.org/~hwright/svn/1.7.0-rc1/
>
> The magic rev is r1159696; please post signatures at the normal location:
> http://work.hyrumwright.org/pub/svn/collect_sigs.py
>
I was testing Subversion 1.7.0-rc1 and got a lot of test failures over svn://. Typical test failure message is:
[[[
CMD: svn.exe cat svn://localhost//svn-test-work/local_tmp/repos/A --config-dir C:\Ivan\server-trunk\Externals\svn-httpd\subversion\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config --password rayjandom --no-auth-cache --username jrandom
CMD: C:\Ivan\server-trunk\Externals\svn-httpd\subversion\Release\subversion\svn\svn.exe cat svn://localhost//svn-test-work/local_tmp/repos/A --config-dir C:\Ivan\server-trunk\Externals\svn-httpd\subversion\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config --password rayjandom --no-auth-cache --username jrandom exited with 1
<TIME = 0.022000>
svn: warning: W195007: URL 'svn://localhost/svn-test-work/local_tmp/repos/A' refers to a directory
svn: E200009: Could not cat all targets because some targets don't exist
EXPECTED STDERR (regexp):
svn: warning: W195007: URL 'svn://localhost//svn-test-work/local_tmp/repos/A' refers to a directory
.*
ACTUAL STDERR:
svn: warning: W195007: URL 'svn://localhost/svn-test-work/local_tmp/repos/A' refers to a directory
svn: E200009: Could not cat all targets because some targets don't exist
CWD: C:\Ivan\server-trunk\Externals\svn-httpd\subversion\Release\subversion\tests\cmdline
EXCEPTION: SVNUnmatchedError
Traceback (most recent call last):
File "C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\svntest\main.py", line 1311, in run
rc = self.pred.run(sandbox)
File "C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\svntest\testcase.py", line 176, in run
return self.func(sandbox)
File "C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\cat_tests.py", line 74, in cat_remote_directory
1, 'cat', A_url)
File "C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\svntest\actions.py", line 307, in run_and_verify_svn2
verify.verify_outputs(message, out, err, expected_stdout, expected_stderr)
File "C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\svntest\verify.py", line 388, in verify_outputs
compare_and_display_lines(message, label, expected, actual, raisable)
File "C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\svntest\verify.py", line 361, in compare_and_display_lines
raise raisable
SVNUnmatchedError
FAIL: cat_tests.py 2: cat a remote directory
]]]
Mention double '/' character in expected error message "svn://localhost//svn-test-work/local_tmp/repos/A". It seems to be some error in our test suite. I'm using Python 2.6.6 on Windows. Is it known problem?
--
Ivan Zhakov
Re: 1.7.0-rc1 up for testing / signing
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, Aug 19, 2011 at 22:24, Hyrum K Wright <hy...@wandisco.com>
wrote:
> Here it is: the first Release Candidate for Subversion 1.7.0. You can
> fetch the proposed tarballs from here:
> http://people.apache.org/~hwright/svn/1.7.0-rc1/
>
> The magic rev is r1159696; please post signatures at the normal location:
> http://work.hyrumwright.org/pub/svn/collect_sigs.py
>
I was testing Subversion 1.7.0-rc1 and got a lot of test failures over
svn://. Typical test failure message is:
[[[
CMD: svn.exe cat svn://localhost//svn-test-work/local_tmp/repos/A
--config-dir
C:\Ivan\server-trunk\Externals\svn-httpd\subversion\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config
--password rayjandom --no-auth-cache --username jrandom
CMD:
C:\Ivan\server-trunk\Externals\svn-httpd\subversion\Release\subversion\svn\svn.exe
cat svn://localhost//svn-test-work/local_tmp/repos/A --config-dir
C:\Ivan\server-trunk\Externals\svn-httpd\subversion\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config
--password rayjandom --no-auth-cache --username jrandom exited with 1
<TIME = 0.022000>
svn: warning: W195007: URL 'svn://localhost/svn-test-work/local_tmp/repos/A'
refers to a directory
svn: E200009: Could not cat all targets because some targets don't exist
EXPECTED STDERR (regexp):
svn: warning: W195007: URL
'svn://localhost//svn-test-work/local_tmp/repos/A' refers to a directory
.*
ACTUAL STDERR:
svn: warning: W195007: URL 'svn://localhost/svn-test-work/local_tmp/repos/A'
refers to a directory
svn: E200009: Could not cat all targets because some targets don't exist
CWD:
C:\Ivan\server-trunk\Externals\svn-httpd\subversion\Release\subversion\tests\cmdline
EXCEPTION: SVNUnmatchedError
Traceback (most recent call last):
File
"C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\svntest\main.py",
line 1311, in run
rc = self.pred.run(sandbox)
File
"C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\svntest\testcase.py",
line 176, in run
return self.func(sandbox)
File
"C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\cat_tests.py",
line 74, in cat_remote_directory
1, 'cat', A_url)
File
"C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\svntest\actions.py",
line 307, in run_and_verify_svn2
verify.verify_outputs(message, out, err, expected_stdout,
expected_stderr)
File
"C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\svntest\verify.py",
line 388, in verify_outputs
compare_and_display_lines(message, label, expected, actual, raisable)
File
"C:\Ivan\server-trunk\Externals\svn-httpd\subversion\subversion\tests\cmdline\svntest\verify.py",
line 361, in compare_and_display_lines
raise raisable
SVNUnmatchedError
FAIL: cat_tests.py 2: cat a remote directory
]]]
Mention double '/' character in expected error message
"svn://localhost//svn-test-work/local_tmp/repos/A". It seems to be some
error in our test suite. I'm using Python 2.6.6 on Windows. Is it known
problem?
--
Ivan Zhakov
Re: 1.7.0-rc1 up for testing / signing
Posted by Mark Phippard <ma...@gmail.com>.
SUMMARY:
+1 to release
PLATFORM:
Windows 7
VS 2008 SP1
Java 1.6
COMPONENTS:
Apache 2.2.19
APR 1.4.5
APR-UTIL 1.3.12
OpenSSL 1.0.0a
Neon 0.29.6
Serf 1.0.0
ZLib 1.2.4
SQLite 3.7.7.1
VERIFIED:
signature and sha1
TESTED:
JavaHL
ra_local | ra_svn | ra_neon | ra_serf X fsfs
RESULTS:
All passed
SIGNATURES:
subversion-1.7.0-rc1.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
iEYEABECAAYFAk5OtvoACgkQJl34oANalqmyZgCglTit7F09vZ/z0XEeynRZUXK0
sTIAoJi0YF7nGN2Cty0Ltb1t+ipyDh43
=RsCF
-----END PGP SIGNATURE-----
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: 1.7.0-rc1 up for testing / signing
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Aug 19, 2011 at 2:24 PM, Hyrum K Wright
<hy...@wandisco.com> wrote:
> Here it is: the first Release Candidate for Subversion 1.7.0. You can
> fetch the proposed tarballs from here:
> http://people.apache.org/~hwright/svn/1.7.0-rc1/
>
> The magic rev is r1159696; please post signatures at the normal location:
> http://work.hyrumwright.org/pub/svn/collect_sigs.py
>
> This is a release candidate, meaning if all goes well it (or something
> very much like it) will become the final release. Please test this as
> if it were the final release, understanding that there will be bugs in
> any software we ship. <insert lecture about perfect being enemy of
> the good here>
>
> To all distributors and binary packagers: This isn't the final
> release. It *won't* be the final release for a few weeks yet, so
> please don't ship it as such. In any case, don't distribute any
> releases based upon these tarballs until we complete our signature
> gathering process and officially announce the release.
>
> -Hyrum
SUMMARY:
---------
+1 to release
VERIFIED:
---------
Hyrum's sig for
http://people.apache.org/~hwright/svn/1.7.0-rc1/deploy/subversion-1.7.0-rc1.zip
Other than the expected differences in
subversion/include/svn_version.h,
http://people.apache.org/~hwright/svn/1.7.0-rc1/deploy/subversion-1.7.0-rc1.zip
is identical to
https://svn.apache.org/repos/asf/subversion/branches/1.7.x@1159696.
TESTED:
-------
[Release-Build] x[ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
Ruby bindings (patched as described here:
http://svn.haxx.se/dev/archive-2011-06/0682.shtml)
JavaHL Bindings
RESULTS:
--------
All Tests Pass
PLATFORM:
---------
MS Windows 7 Home Premium Service Pack 1
Microsoft Visual Studio 2008 Version 9.0.30729.1 SP
DEPENDENCIES:
-------------
APR: 1.4.5
APR-UTIL: 1.3.12
Neon: 0.29.5
zlib: 1.2.4
OpenSSL: 0.9.8q
Apache: 2.2.19
BDB: 4.8.30
sqlite: 3.7.7.1
Python: 2.6.6 (ActivePython 2.6.6.17)
Perl: 5.10.1
Ruby: ruby 1.8.7
java: 1.6.0_21
junit: 4.8.2
swig: 1.3.40
serf: 1.0.0
SIGNATURE:
----------
http://people.apache.org/~hwright/svn/1.7.0-rc1/deploy/subversion-1.7.0-rc1.zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
iD8DBQBOUEeh2RaJMFP83FURAtUlAJkBrIHW3vsD9LK1lL/+NGWp4boP+ACcD2Ps
RHsw+/YNhe6NEtYxuPOZSTs=
=dxlg
-----END PGP SIGNATURE-----
Paul