<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 2:33 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 06/16/2014 05:06 PM, Ben Nemec wrote:<br>
> On 06/16/2014 12:01 PM, Sean Dague wrote:<br>
>> On 06/16/2014 12:44 PM, Ben Nemec wrote:<br>
>>> On 06/16/2014 08:37 AM, Thierry Carrez wrote:<br>
>>>> Sean Dague wrote:<br>
>>>>> Hacking 0.9 series was released pretty late for Juno. The<br>
>>>>> entire check queue was flooded this morning with requirements<br>
>>>>> proposals failing pep8 because of it (so at 6am EST we were<br>
>>>>> waiting 1.5 hrs for a check node).<br>
>>>>><br>
>>>>> The previous soft policy with pep8 updates was that we set a<br>
>>>>> pep8 version basically release week, and changes stopped<br>
>>>>> being done for style after first milestone.<br>
>>>>><br>
>>>>> I think in the spirit of that we should revert the hacking<br>
>>>>> requirements update back to the 0.8 series for Juno. We're<br>
>>>>> past milestone 1, so shouldn't be working on style only fixes<br>
>>>>> at this point.<br>
>>>>><br>
>>>>> Proposed review here -<br>
>>>>> <a href="https://review.openstack.org/#/c/100231/" target="_blank">https://review.openstack.org/#/c/100231/</a><br>
>>>>><br>
>>>>> I also think in future hacking major releases need to happen<br>
>>>>> within one week of release, or not at all for that series.<br>
>>><br>
>>>> We may also have reached a size where changing style rules is<br>
>>>> just too costly, whatever the moment in the cycle. I think it's<br>
>>>> good that we have rules to enforce a minimum of common style,<br>
>>>> but the added value of those extra rules is limited, while<br>
>>>> their impact on the common gate grows as we add more projects.<br>
>>><br>
>>> A few thoughts:<br>
>>><br>
>>> 1) I disagree with the proposition that hacking updates can only<br>
>>> happen in the first week after release. I get that there needs<br>
>>> to be a cutoff, but I don't think one week is reasonable. Even<br>
>>> if we release in the first week, you're still going to be dealing<br>
>>> with hacking updates for the rest of the cycle as projects adopt<br>
>>> the new rules at their leisure. I don't like retroactively<br>
>>> applying milestone 1 as a cutoff either, although I could see<br>
>>> making that the policy going forward.<br>
>>><br>
>>> 2) Given that most of the changes involved in fixing the new<br>
>>> failures are trivial, I think we should encourage combining the<br>
>>> fixes into one commit. We _really_ don't need separate commits<br>
>>> to fix H305 and H307. This doesn't help much with the reviewer<br>
>>> load, but it should reduce the gate load somewhat. It violates<br>
>>> the one change-one commit rule, but "A foolish consistency..."<br>
><br>
>> The challenge is that hacking updates are basically giant merge<br>
>> conflict engines. If there is any significant amount of code<br>
>> outstanding in a project, landing hacking only changes basically<br>
>> means requiring much of the outstanding code to rebase.<br>
><br>
>> So it's actually expensive in a way that doesn't jump out<br>
>> immediately. The cost of landing hacking isn't just the code of<br>
>> reviewing the hacking patches, it's also the cost of the extra<br>
>> roundtrips on outstanding patches.<br>
><br>
> If a project has that many violations of a new hacking rule then I'd<br>
> say they should just leave it disabled. It already happens and I'd<br>
> rather have that than throw out a rule just because some projects<br>
> haven't been following it.<br>
<br>
</div></div>That would be fine if the propose bot *also* proposed the tox.ini<br>
ignores, which it does not.<br>
<br>
So it pushes a largely by definition broken patch that consumes<br>
resources, and will require a human to take it over. If a person did<br>
this on a regular basis, we'd have a stern talking to them. Or at least<br>
a light making fun of them.<br>
<br>
It feels like robo auto propose should be limited to the class of things<br>
where the patch is 99% sure to pass.<br></blockquote><div><br></div><div>I feel the same way on this one, for some reason I was originally under the impression that hacking had to manually be rolled out because of the reasons above.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Which I think is really the crux of my distaste for hacking breaking<br>
updates auto proposing to projects.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Sean<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>