You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2010/03/31 14:05:19 UTC
Vetoing latest issue #3020 fix in 1.6.10
Mike and I were discussing the changes I made in
http://svn.apache.org/viewvc?view=revision&revision=927243 to fix
issue #3020 and which were backported to 1.6.x. There is a regression
in that fix and I am changing my vote to -1 and pulling it from 1.6.x
(and today's roll of 1.6.10).
The fix in r927243 addressed the problem of mergeinfo in a partial
dump of a repository, specifically:
We dump -r(X>1):Y from repos A then load that dump into repos B. If
there is mergeinfo in the loaded revisions it may refer to revisions <
X. r927423 strips out these ranges. This is fine if the partial dump
of repos A is done in one step, e.g,
svnadmin dump reposA -r200:300 > A.200.300.partial.dump
svnadmin load reposB < A.200.300.partial.dump
because those revisions don't refer to valid history re the
mergeinfo's merge source.
Unfortunately this fix breaks a (likely much more) common use case:
Dumping a complete repository in multiple steps and then loading each
chunk to the new repository, e.g.:
svnadmin dump reposA -r0:100 > A.0.100.dump
svnadmin dump reposA -r101:200 --incremental > A.101.200.dump
svnadmin dump reposA -r201:300 --incremental > A.201.300.dump
svnadmin load reposB < A.0.100.dump
svnadmin load reposB < A.101.200.dump
svnadmin load reposB < A.201.300.dump
In this case, valid mergeinfo may be filtered from the 2nd and or 3rd load.
I'll work on a fix that can handle both use cases, but for now I am
changing my vote to -1 and reverting this backport.
Paul
Re: RFC: Release process amendment (was Re: Vetoing latest issue
#3020 fix in 1.6.10)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Mar 31, 2010 at 8:10 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Hyrum K. Wright wrote:
>>> I'll work on a fix that can handle both use cases, but for now I am
>>> changing my vote to -1 and reverting this backport.
>>>
>>
>> And just so folks know, Paul's got the RM's blessing on this.
>
> Great that he has your blessing, but I would suggest that he really doesn't
> need it. We necessarily must allow for -1's to come late to the party in
> the backport process, and for them to be binding-to-the-point-of-reversion,
> even if they come -- heck, *especially* if they come -- from the person who
> previously proposed or voted affirmatively for a backport.
>
> In fact, I would argue that we should never roll a release within so many
> days of the most recent backport to the release branch, just to avoid any
> threesome getting together to, intentionally or otherwise, railroad
> last-minute changes into a release without time for other eyeballs. Why the
> backport as the time-critical piece instead of the STATUS votes? Because
> the backport generates a commit mail that folks are more likely to pay real
> attention to than the STATUS churn.
>
> What do others think about this? Could we live with a policy change that
> says that a release can only be cut 24 weekday hours after the most recent
> non-trivial backport to its branch?
IMO, it's not necessary and should be left to the RM's discretion
rather than a formal policy change. If you can really get three
people to collude on an 'evil' change *and* the RM agrees with
including it in the release, so be it. If you want to hit those three
with a wet sock full of rocks afterwards, have fun. But, the reason
why we require three people to sign off is to ensure adequate review -
I don't think we need to have another gating mechanism.
FWIW, this goes to the idea that releases can not be vetoed. If the
RM is okay with including it, that's the final say. If you don't like
the decisions the RM makes, you too can be an RM. =P
My $.02. -- justin
Re: RFC: Release process amendment (was Re: Vetoing latest issue
#3020 fix in 1.6.10)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Hyrum K. Wright wrote on Wed, 31 Mar 2010 at 10:41 -0500:
> The counter-argument, of course, is that we set the deadline not at
> the time of tag, but at the time of when the last merge can be
> performed. While possible, we may lack the discipline to *not*
> include a fix which receives its third vote shortly after this
> deadline, and for which there is significant community momentum. We
> could make exceptions, but once that happens, it's a slippery slope
> back to where we are today.
To avoid this, perhaps we could make the policy to delay the tag until
24 hours after the merge of the fix-included-by-exception.
Re: RFC: Release process amendment (was Re: Vetoing latest issue #3020 fix in 1.6.10)
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 31, 2010, at 10:10 AM, C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>>> I'll work on a fix that can handle both use cases, but for now I am
>>> changing my vote to -1 and reverting this backport.
>>>
>>
>> And just so folks know, Paul's got the RM's blessing on this.
>
> Great that he has your blessing, but I would suggest that he really doesn't
> need it. We necessarily must allow for -1's to come late to the party in
> the backport process, and for them to be binding-to-the-point-of-reversion,
> even if they come -- heck, *especially* if they come -- from the person who
> previously proposed or voted affirmatively for a backport.
My statement was really meant to indicate that Paul and I were coordinating this effort, since today has been the planned day of a release for the last 2 weeks. It would be at least a little confusing if folks started yanking stuff from the branch on the day of a release *without* involving the RM.
But your point about folks choosing to -1 stuff after the fact is well taken. I don't see any circumstance in which the RM would intentionally stand in the way of somebody backing out a vetoed change.
> In fact, I would argue that we should never roll a release within so many
> days of the most recent backport to the release branch, just to avoid any
> threesome getting together to, intentionally or otherwise, railroad
> last-minute changes into a release without time for other eyeballs. Why the
> backport as the time-critical piece instead of the STATUS votes? Because
> the backport generates a commit mail that folks are more likely to pay real
> attention to than the STATUS churn.
>
> What do others think about this? Could we live with a policy change that
> says that a release can only be cut 24 weekday hours after the most recent
> non-trivial backport to its branch?
We actually have a bit of history in doing the opposite: a flurry of nominations, review, lobbying, voting, and merging just prior to the release. I'm a bit concerned that if we did implement a delay-release policy, it would degrade the quality of the release, or undesirably postpone releases.
The counter-argument, of course, is that we set the deadline not at the time of tag, but at the time of when the last merge can be performed. While possible, we may lack the discipline to *not* include a fix which receives its third vote shortly after this deadline, and for which there is significant community momentum. We could make exceptions, but once that happens, it's a slippery slope back to where we are today.
-Hyrum
Re: RFC: Release process amendment (was Re: Vetoing latest issue #3020 fix in 1.6.10)
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 31, 2010, at 10:10 AM, C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>>> I'll work on a fix that can handle both use cases, but for now I am
>>> changing my vote to -1 and reverting this backport.
>>>
>>
>> And just so folks know, Paul's got the RM's blessing on this.
>
> Great that he has your blessing, but I would suggest that he really doesn't
> need it. We necessarily must allow for -1's to come late to the party in
> the backport process, and for them to be binding-to-the-point-of-reversion,
> even if they come -- heck, *especially* if they come -- from the person who
> previously proposed or voted affirmatively for a backport.
My statement was really meant to indicate that Paul and I were coordinating this effort, since today has been the planned day of a release for the last 2 weeks. It would be at least a little confusing if folks started yanking stuff from the branch on the day of a release *without* involving the RM.
But your point about folks choosing to -1 stuff after the fact is well taken. I don't see any circumstance in which the RM would intentionally stand in the way of somebody backing out a vetoed change.
> In fact, I would argue that we should never roll a release within so many
> days of the most recent backport to the release branch, just to avoid any
> threesome getting together to, intentionally or otherwise, railroad
> last-minute changes into a release without time for other eyeballs. Why the
> backport as the time-critical piece instead of the STATUS votes? Because
> the backport generates a commit mail that folks are more likely to pay real
> attention to than the STATUS churn.
>
> What do others think about this? Could we live with a policy change that
> says that a release can only be cut 24 weekday hours after the most recent
> non-trivial backport to its branch?
We actually have a bit of history in doing the opposite: a flurry of nominations, review, lobbying, voting, and merging just prior to the release. I'm a bit concerned that if we did implement a delay-release policy, it would degrade the quality of the release, or undesirably postpone releases.
The counter-argument, of course, is that we set the deadline not at the time of tag, but at the time of when the last merge can be performed. While possible, we may lack the discipline to *not* include a fix which receives its third vote shortly after this deadline, and for which there is significant community momentum. We could make exceptions, but once that happens, it's a slippery slope back to where we are today.
-Hyrum
Re: RFC: Release process amendment (was Re: Vetoing latest issue
#3020 fix in 1.6.10)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Stein wrote:
> On Wed, Mar 31, 2010 at 11:21, Mark Phippard <ma...@gmail.com> wrote:
>> On Wed, Mar 31, 2010 at 11:10 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>> Hyrum K. Wright wrote:
>>>>> I'll work on a fix that can handle both use cases, but for now I am
>>>>> changing my vote to -1 and reverting this backport.
>>>>>
>>>> And just so folks know, Paul's got the RM's blessing on this.
>>> Great that he has your blessing, but I would suggest that he really doesn't
>>> need it. We necessarily must allow for -1's to come late to the party in
>>> the backport process, and for them to be binding-to-the-point-of-reversion,
>>> even if they come -- heck, *especially* if they come -- from the person who
>>> previously proposed or voted affirmatively for a backport.
>>>
>>> In fact, I would argue that we should never roll a release within so many
>>> days of the most recent backport to the release branch, just to avoid any
>>> threesome getting together to, intentionally or otherwise, railroad
>>> last-minute changes into a release without time for other eyeballs. Why the
>>> backport as the time-critical piece instead of the STATUS votes? Because
>>> the backport generates a commit mail that folks are more likely to pay real
>>> attention to than the STATUS churn.
>>>
>>> What do others think about this? Could we live with a policy change that
>>> says that a release can only be cut 24 weekday hours after the most recent
>>> non-trivial backport to its branch?
>> I would be against this (-1) until such time that it manifested as a
>> problem. The current system has been too valuable in resolving things
>> like fixes to the bindings that no one had bothered to look at etc.
>> Most importantly, the scenario you describe just has not been an
>> actual problem we have faced so there is no need to develop a policy
>> to block it.
>
> I'm with Mark on this one.
>
> The RM has a brain, and is given the "use your best judgement" baton.
> We have ways to resolve RM problems.
Good points, all. I retract the suggestion (and publicly admit my own
tendency to often wish to resolve questions before they are asked).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: RFC: Release process amendment (was Re: Vetoing latest issue
#3020 fix in 1.6.10)
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Mar 31, 2010 at 11:21, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, Mar 31, 2010 at 11:10 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> Hyrum K. Wright wrote:
>>>> I'll work on a fix that can handle both use cases, but for now I am
>>>> changing my vote to -1 and reverting this backport.
>>>>
>>>
>>> And just so folks know, Paul's got the RM's blessing on this.
>>
>> Great that he has your blessing, but I would suggest that he really doesn't
>> need it. We necessarily must allow for -1's to come late to the party in
>> the backport process, and for them to be binding-to-the-point-of-reversion,
>> even if they come -- heck, *especially* if they come -- from the person who
>> previously proposed or voted affirmatively for a backport.
>>
>> In fact, I would argue that we should never roll a release within so many
>> days of the most recent backport to the release branch, just to avoid any
>> threesome getting together to, intentionally or otherwise, railroad
>> last-minute changes into a release without time for other eyeballs. Why the
>> backport as the time-critical piece instead of the STATUS votes? Because
>> the backport generates a commit mail that folks are more likely to pay real
>> attention to than the STATUS churn.
>>
>> What do others think about this? Could we live with a policy change that
>> says that a release can only be cut 24 weekday hours after the most recent
>> non-trivial backport to its branch?
>
> I would be against this (-1) until such time that it manifested as a
> problem. The current system has been too valuable in resolving things
> like fixes to the bindings that no one had bothered to look at etc.
> Most importantly, the scenario you describe just has not been an
> actual problem we have faced so there is no need to develop a policy
> to block it.
I'm with Mark on this one.
The RM has a brain, and is given the "use your best judgement" baton.
We have ways to resolve RM problems.
Cheers,
-g
Re: RFC: Release process amendment (was Re: Vetoing latest issue
#3020 fix in 1.6.10)
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Mar 31, 2010 at 11:10 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Hyrum K. Wright wrote:
>>> I'll work on a fix that can handle both use cases, but for now I am
>>> changing my vote to -1 and reverting this backport.
>>>
>>
>> And just so folks know, Paul's got the RM's blessing on this.
>
> Great that he has your blessing, but I would suggest that he really doesn't
> need it. We necessarily must allow for -1's to come late to the party in
> the backport process, and for them to be binding-to-the-point-of-reversion,
> even if they come -- heck, *especially* if they come -- from the person who
> previously proposed or voted affirmatively for a backport.
>
> In fact, I would argue that we should never roll a release within so many
> days of the most recent backport to the release branch, just to avoid any
> threesome getting together to, intentionally or otherwise, railroad
> last-minute changes into a release without time for other eyeballs. Why the
> backport as the time-critical piece instead of the STATUS votes? Because
> the backport generates a commit mail that folks are more likely to pay real
> attention to than the STATUS churn.
>
> What do others think about this? Could we live with a policy change that
> says that a release can only be cut 24 weekday hours after the most recent
> non-trivial backport to its branch?
I would be against this (-1) until such time that it manifested as a
problem. The current system has been too valuable in resolving things
like fixes to the bindings that no one had bothered to look at etc.
Most importantly, the scenario you describe just has not been an
actual problem we have faced so there is no need to develop a policy
to block it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RFC: Release process amendment (was Re: Vetoing latest issue #3020
fix in 1.6.10)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Hyrum K. Wright wrote:
>> I'll work on a fix that can handle both use cases, but for now I am
>> changing my vote to -1 and reverting this backport.
>>
>
> And just so folks know, Paul's got the RM's blessing on this.
Great that he has your blessing, but I would suggest that he really doesn't
need it. We necessarily must allow for -1's to come late to the party in
the backport process, and for them to be binding-to-the-point-of-reversion,
even if they come -- heck, *especially* if they come -- from the person who
previously proposed or voted affirmatively for a backport.
In fact, I would argue that we should never roll a release within so many
days of the most recent backport to the release branch, just to avoid any
threesome getting together to, intentionally or otherwise, railroad
last-minute changes into a release without time for other eyeballs. Why the
backport as the time-critical piece instead of the STATUS votes? Because
the backport generates a commit mail that folks are more likely to pay real
attention to than the STATUS churn.
What do others think about this? Could we live with a policy change that
says that a release can only be cut 24 weekday hours after the most recent
non-trivial backport to its branch?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Vetoing latest issue #3020 fix in 1.6.10
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Mar 31, 2010 at 10:13 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
>
> On Wed, Mar 31, 2010 at 8:05 AM, Paul Burba <pt...@gmail.com> wrote:
>>
>> Mike and I were discussing the changes I made in
>> http://svn.apache.org/viewvc?view=revision&revision=927243 to fix
>> issue #3020 and which were backported to 1.6.x. There is a regression
>> in that fix and I am changing my vote to -1 and pulling it from 1.6.x
>> (and today's roll of 1.6.10).
>>
>> The fix in r927243 addressed the problem of mergeinfo in a partial
>> dump of a repository, specifically:
>>
>> We dump -r(X>1):Y from repos A then load that dump into repos B. If
>> there is mergeinfo in the loaded revisions it may refer to revisions <
>> X. r927423 strips out these ranges. This is fine if the partial dump
>> of repos A is done in one step, e.g,
>>
>> svnadmin dump reposA -r200:300 > A.200.300.partial.dump
>> svnadmin load reposB < A.200.300.partial.dump
>>
>> because those revisions don't refer to valid history re the
>> mergeinfo's merge source.
>>
>> Unfortunately this fix breaks a (likely much more) common use case:
>> Dumping a complete repository in multiple steps and then loading each
>> chunk to the new repository, e.g.:
>>
>> svnadmin dump reposA -r0:100 > A.0.100.dump
>> svnadmin dump reposA -r101:200 --incremental > A.101.200.dump
>> svnadmin dump reposA -r201:300 --incremental > A.201.300.dump
>>
>> svnadmin load reposB < A.0.100.dump
>> svnadmin load reposB < A.101.200.dump
>> svnadmin load reposB < A.201.300.dump
>>
>> In this case, valid mergeinfo may be filtered from the 2nd and or 3rd
>> load.
>>
>> I'll work on a fix that can handle both use cases, but for now I am
>> changing my vote to -1 and reverting this backport.
>
> And just so folks know, Paul's got the RM's blessing on this.
Reverted http://svn.apache.org/viewvc?view=revision&revision=929548
Now to fix the fix...
Paul
Re: Vetoing latest issue #3020 fix in 1.6.10
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Wed, Mar 31, 2010 at 8:05 AM, Paul Burba <pt...@gmail.com> wrote:
> Mike and I were discussing the changes I made in
> http://svn.apache.org/viewvc?view=revision&revision=927243 to fix
> issue #3020 and which were backported to 1.6.x. There is a regression
> in that fix and I am changing my vote to -1 and pulling it from 1.6.x
> (and today's roll of 1.6.10).
>
> The fix in r927243 addressed the problem of mergeinfo in a partial
> dump of a repository, specifically:
>
> We dump -r(X>1):Y from repos A then load that dump into repos B. If
> there is mergeinfo in the loaded revisions it may refer to revisions <
> X. r927423 strips out these ranges. This is fine if the partial dump
> of repos A is done in one step, e.g,
>
> svnadmin dump reposA -r200:300 > A.200.300.partial.dump
> svnadmin load reposB < A.200.300.partial.dump
>
> because those revisions don't refer to valid history re the
> mergeinfo's merge source.
>
> Unfortunately this fix breaks a (likely much more) common use case:
> Dumping a complete repository in multiple steps and then loading each
> chunk to the new repository, e.g.:
>
> svnadmin dump reposA -r0:100 > A.0.100.dump
> svnadmin dump reposA -r101:200 --incremental > A.101.200.dump
> svnadmin dump reposA -r201:300 --incremental > A.201.300.dump
>
> svnadmin load reposB < A.0.100.dump
> svnadmin load reposB < A.101.200.dump
> svnadmin load reposB < A.201.300.dump
>
> In this case, valid mergeinfo may be filtered from the 2nd and or 3rd load.
>
> I'll work on a fix that can handle both use cases, but for now I am
> changing my vote to -1 and reverting this backport.
>
And just so folks know, Paul's got the RM's blessing on this.
-Hyrum