You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2011/08/23 21:03:15 UTC
Re: rc1 is DOA. What now?
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?
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.