You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by st...@apache.org on 2012/02/26 08:47:02 UTC
svn commit: r1293766 - /subversion/branches/1.7.x/STATUS
Author: steveking
Date: Sun Feb 26 07:47:02 2012
New Revision: 1293766
URL: http://svn.apache.org/viewvc?rev=1293766&view=rev
Log:
* STATUS: Vote and approve r1235831, r1236099 and r1292090, r1292827
Modified:
subversion/branches/1.7.x/STATUS
Modified: subversion/branches/1.7.x/STATUS
URL: http://svn.apache.org/viewvc/subversion/branches/1.7.x/STATUS?rev=1293766&r1=1293765&r2=1293766&view=diff
==============================================================================
--- subversion/branches/1.7.x/STATUS (original)
+++ subversion/branches/1.7.x/STATUS Sun Feb 26 07:47:02 2012
@@ -15,16 +15,6 @@ Status of 1.7.4:
Candidate changes:
==================
- * r1235831, r1236099
- Tweak the parsing of the ssl-authority-files config option to make it
- easier for users to configure.
- Justification:
- Low impact change to help users.
- Notes:
- Both r1235831 and r1236099 conflict and will need a branch.
- Votes:
- +1: gstein, rhuijben
-
* r1200277, r1243694, r1243840, r1243920, r1244466, r1244551
Workaround for issue #4087, "bogus repos_id in wc.db for file externals"
Justification:
@@ -70,18 +60,6 @@ Candidate changes:
Votes:
+1: stsp, rhuijben
- * r1292090, r1292827
- Fix issue #4123 'URL-to-WC copy of externals fails on Windows'.
- Justification:
- URL-to-WC copies of externals are broken without this fix. This is
- a regression from 1.6.
- Notes:
- r1292090 is a regression test and r1292827 is the fix.
- Branch:
- ^/subversion/branches/1.7.x-issue4123
- Votes:
- +1: pburba, stsp
-
Veto-blocked changes:
=====================
@@ -116,3 +94,26 @@ Approved changes:
r1245284 and r1245285 implement a fix.
Votes:
+1: stsp, julianfoad, rhuijben
+
+ * r1235831, r1236099
+ Tweak the parsing of the ssl-authority-files config option to make it
+ easier for users to configure.
+ Justification:
+ Low impact change to help users.
+ Notes:
+ Both r1235831 and r1236099 conflict and will need a branch.
+ Votes:
+ +1: gstein, rhuijben, steveking
+
+ * r1292090, r1292827
+ Fix issue #4123 'URL-to-WC copy of externals fails on Windows'.
+ Justification:
+ URL-to-WC copies of externals are broken without this fix. This is
+ a regression from 1.6.
+ Notes:
+ r1292090 is a regression test and r1292827 is the fix.
+ Branch:
+ ^/subversion/branches/1.7.x-issue4123
+ Votes:
+ +1: pburba, stsp, steveking
+
Re: svn commit: r1293766 - /subversion/branches/1.7.x/STATUS
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/27/2012 06:22 AM, Stefan Sperling wrote:
> On Mon, Feb 27, 2012 at 09:40:57AM +0000, Julian Foad wrote:
>> For reference, r1235831's log message is:
>>
>> > Improve the handling of the ssl-authority-files config option:
>> > allow leading and trailing whitespace on the filenames to make
>> > it easier for the user to format the list of files.
>>
>> Are we willing to break our compatibility guarantees for the sake of
>> this convenience? I've added my veto to the STATUS file pending the
>> outcome of this discussion.
>
> I, too, think this doesn't make sense to backport.
> It's a behaviour change, rather than a bug fix.
>
> We also blocked changes like r1221463 from being backported, because
> cmpilato argued that "a rollback to an earlier patch release would
> break any bookmarks saved for URLs using the new syntax"
>
> The same problem can happen with configuration file changes such as this.
> We cannot control what happens to user configuration files during
> upgrade/downgrade.
Right. We've always operated under the assumption that if someone needed to
roll back to a previous patch release, the only change they experience is
the loss of bugfixes made since that patch release. If rolling back in this
case means that their config files no longer parse, that's a brand new
problem introduced by the rollback -- we don't want to go there.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r1293766 - /subversion/branches/1.7.x/STATUS
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/27/2012 06:22 AM, Stefan Sperling wrote:
> On Mon, Feb 27, 2012 at 09:40:57AM +0000, Julian Foad wrote:
>> For reference, r1235831's log message is:
>>
>> > Improve the handling of the ssl-authority-files config option:
>> > allow leading and trailing whitespace on the filenames to make
>> > it easier for the user to format the list of files.
>>
>> Are we willing to break our compatibility guarantees for the sake of
>> this convenience? I've added my veto to the STATUS file pending the
>> outcome of this discussion.
>
> I, too, think this doesn't make sense to backport.
> It's a behaviour change, rather than a bug fix.
>
> We also blocked changes like r1221463 from being backported, because
> cmpilato argued that "a rollback to an earlier patch release would
> break any bookmarks saved for URLs using the new syntax"
>
> The same problem can happen with configuration file changes such as this.
> We cannot control what happens to user configuration files during
> upgrade/downgrade.
Right. We've always operated under the assumption that if someone needed to
roll back to a previous patch release, the only change they experience is
the loss of bugfixes made since that patch release. If rolling back in this
case means that their config files no longer parse, that's a brand new
problem introduced by the rollback -- we don't want to go there.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r1293766 - /subversion/branches/1.7.x/STATUS
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Feb 27, 2012 at 09:40:57AM +0000, Julian Foad wrote:
> steveking@apache.org wrote on Sun, Feb 26, 2012 at 07:47:02 -0000:
>
> > + * r1235831, r1236099
> > + Tweak the parsing of the ssl-authority-files config option to make it
> > + easier for users to configure.
> > + Justification:
> > + Low impact change to help users.
> > + Notes:
> > + Both r1235831 and r1236099 conflict and will need a branch.
> > + Votes:
> > + +1: gstein, rhuijben, steveking
>
> It looks like a lovely change for 1.8, but am I the only one who thinks we shouldn't back-port this because it isn't
> forward-compatible? That is, Subversion 1.7.0 isn't compatible with
> configurations created by a user of this patch.
>
> For reference, r1235831's log message is:
>
> > Improve the handling of the ssl-authority-files config option:
> > allow leading and trailing whitespace on the filenames to make
> > it easier for the user to format the list of files.
>
> Are we willing to break our compatibility guarantees for the sake of
> this convenience? I've added my veto to the STATUS file pending the
> outcome of this discussion.
I, too, think this doesn't make sense to backport.
It's a behaviour change, rather than a bug fix.
We also blocked changes like r1221463 from being backported, because
cmpilato argued that "a rollback to an earlier patch release would
break any bookmarks saved for URLs using the new syntax"
The same problem can happen with configuration file changes such as this.
We cannot control what happens to user configuration files during
upgrade/downgrade.
Re: svn commit: r1293766 - /subversion/branches/1.7.x/STATUS
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Feb 27, 2012 at 09:40:57AM +0000, Julian Foad wrote:
> steveking@apache.org wrote on Sun, Feb 26, 2012 at 07:47:02 -0000:
>
> > + * r1235831, r1236099
> > + Tweak the parsing of the ssl-authority-files config option to make it
> > + easier for users to configure.
> > + Justification:
> > + Low impact change to help users.
> > + Notes:
> > + Both r1235831 and r1236099 conflict and will need a branch.
> > + Votes:
> > + +1: gstein, rhuijben, steveking
>
> It looks like a lovely change for 1.8, but am I the only one who thinks we shouldn't back-port this because it isn't
> forward-compatible? That is, Subversion 1.7.0 isn't compatible with
> configurations created by a user of this patch.
>
> For reference, r1235831's log message is:
>
> > Improve the handling of the ssl-authority-files config option:
> > allow leading and trailing whitespace on the filenames to make
> > it easier for the user to format the list of files.
>
> Are we willing to break our compatibility guarantees for the sake of
> this convenience? I've added my veto to the STATUS file pending the
> outcome of this discussion.
I, too, think this doesn't make sense to backport.
It's a behaviour change, rather than a bug fix.
We also blocked changes like r1221463 from being backported, because
cmpilato argued that "a rollback to an earlier patch release would
break any bookmarks saved for URLs using the new syntax"
The same problem can happen with configuration file changes such as this.
We cannot control what happens to user configuration files during
upgrade/downgrade.
Re: svn commit: r1293766 - /subversion/branches/1.7.x/STATUS
Posted by Julian Foad <ju...@btopenworld.com>.
steveking@apache.org wrote on Sun, Feb 26, 2012 at 07:47:02 -0000:
> + * r1235831, r1236099
> + Tweak the parsing of the ssl-authority-files config option to make it
> + easier for users to configure.
> + Justification:
> + Low impact change to help users.
> + Notes:
> + Both r1235831 and r1236099 conflict and will need a branch.
> + Votes:
> + +1: gstein, rhuijben, steveking
It looks like a lovely change for 1.8, but am I the only one who thinks we shouldn't back-port this because it isn't
forward-compatible? That is, Subversion 1.7.0 isn't compatible with
configurations created by a user of this patch.
For reference, r1235831's log message is:
> Improve the handling of the ssl-authority-files config option:
> allow leading and trailing whitespace on the filenames to make
> it easier for the user to format the list of files.
Are we willing to break our compatibility guarantees for the sake of this convenience? I've added my veto to the STATUS file pending the outcome of this discussion.
- Julian
Re: svn commit: r1293766 - /subversion/branches/1.7.x/STATUS
Posted by Julian Foad <ju...@btopenworld.com>.
steveking@apache.org wrote on Sun, Feb 26, 2012 at 07:47:02 -0000:
> + * r1235831, r1236099
> + Tweak the parsing of the ssl-authority-files config option to make it
> + easier for users to configure.
> + Justification:
> + Low impact change to help users.
> + Notes:
> + Both r1235831 and r1236099 conflict and will need a branch.
> + Votes:
> + +1: gstein, rhuijben, steveking
It looks like a lovely change for 1.8, but am I the only one who thinks we shouldn't back-port this because it isn't
forward-compatible? That is, Subversion 1.7.0 isn't compatible with
configurations created by a user of this patch.
For reference, r1235831's log message is:
> Improve the handling of the ssl-authority-files config option:
> allow leading and trailing whitespace on the filenames to make
> it easier for the user to format the list of files.
Are we willing to break our compatibility guarantees for the sake of this convenience? I've added my veto to the STATUS file pending the outcome of this discussion.
- Julian
Re: svn commit: r1293766 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
steveking@apache.org wrote on Sun, Feb 26, 2012 at 07:47:02 -0000:
> + * r1235831, r1236099
> + Tweak the parsing of the ssl-authority-files config option to make it
> + easier for users to configure.
> + Justification:
> + Low impact change to help users.
> + Notes:
> + Both r1235831 and r1236099 conflict and will need a branch.
> + Votes:
> + +1: gstein, rhuijben, steveking
Is someone going to provide a branch?
Re: svn commit: r1293766 - /subversion/branches/1.7.x/STATUS
Posted by Daniel Shahaf <da...@elego.de>.
steveking@apache.org wrote on Sun, Feb 26, 2012 at 07:47:02 -0000:
> + * r1235831, r1236099
> + Tweak the parsing of the ssl-authority-files config option to make it
> + easier for users to configure.
> + Justification:
> + Low impact change to help users.
> + Notes:
> + Both r1235831 and r1236099 conflict and will need a branch.
> + Votes:
> + +1: gstein, rhuijben, steveking
Is someone going to provide a branch?