Open Stack

On 08/14/2014 11:11 AM, Daniel P. Berrange wrote:
> On Thu, Aug 14, 2014 at 10:06:13AM +0100, Mark McLoughlin wrote:
>> On Tue, 2014-08-12 at 15:56 +0100, Mark McLoughlin wrote:
>>> Hey
>>>
>>> (Terrible name for a policy, I know)
>>>
>>> From the version_cap saga here:
>>>
>>>   https://review.openstack.org/110754
>>>
>>> I think we need a better understanding of how to approach situations
>>> like this.
>>>
>>> Here's my attempt at documenting what I think we're expecting the
>>> procedure to be:
>>>
>>>   https://etherpad.openstack.org/p/nova-retrospective-veto-revert-policy
>>>
>>> If it sounds reasonably sane, I can propose its addition to the
>>> "Development policies" doc.
>>
>> (In the spirit of "we really need to step back and laugh at ourselves
>> sometimes" ... )
>>
>> Two years ago, we were worried about patches getting merged in less than
>> 2 hours and had a discussion about imposing a minimum review time. How
>> times have changed! Is it even possible to land a patch in less than two
>> hours now? :)
>>
>> Looking back over the thread, this part stopped me in my tracks:
>>
>>   https://lists.launchpad.net/openstack/msg08625.html
>>
>>     On Tue, Mar 13, 2012, Mark McLoughlin <markmc at xxxxxxxxxx> wrote:
>>
>>     > Sometimes there can be a few folks working through an issue together and
>>     > the patch gets pushed and approved so quickly that no-one else gets a
>>     > chance to review.
>>
>>     Everyone has an opportunity to review even after a patch gets merged.
>>
>>     JE
>>
>> It's not quite perfect, but if you squint you could conclude that
>> Johannes and I have both completely reversed our opinions in the
>> intervening two years :)
>>
>> The lesson I take from that is to not get too caught up in the current
>> moment. We're growing and evolving rapidly. If we assume everyone is
>> acting in good faith, and allow each other to debate earnestly without
>> feelings getting hurt ... we should be able to work through anything.
>>
>> Now, back on topic - digging through that thread, it doesn't seem we
>> settled on the idea of "we can just revert it later if someone has an
>> objection" in this thread. Does anyone recall when that idea first came
>> up?
> 
> Probably lost in time - I've seen it said several times on Nova IRC
> channel over the year(s) when we made a strategic decision to merge
> something quickly.
> 

Another vote for "revert early revert often" here.

Having said that - as chance would have it, I am in the middle of
proposing a revert on a different thread [1]. I did not propose a revert
patch before starting the discussion first since it's a feature that has
been cooking for some time now, people involved seem to be on holidays,
and I just simply never managed to look closely enough until it merged,
and I, by chance again, was working on something that could potentially
use it which brought it's defects to my attention.

I think even in this situation when we have a long standing feature - it
should be fair game for reverting *, as long as revert is backed with
legitimate technical arguments. There should be no hard feelings when
technical arguments are sound enough. We can and should talk about it in
details later, and make sure we are seen all angle, but do revert early.

Even with best of intentions, I would not have looked at it in time -
Nova is just too big at this point, at least for me.

So I propose a small addition to the "revert early, revert often"
catchphrase - "have solid technical arguments."**

N.

* v3 API is on a whole different order of magnitude and should not be
used in this discussion IMHO, hopefully something like that does not
come up often enough to warrant a rule.

** Not to imply that I do in [1], but solid technical arguments can
never include quoting obscure policies or "pulling rank", among other
things.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-August/042709.html