On Wed, Mar 31, 2010 at 11:10 AM, C. Michael Pilato <cmpilato_at_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/
Received on 2010-03-31 17:21:41 CEST