Open Stack

On 06/16/2014 05:06 PM, Ben Nemec wrote:
> On 06/16/2014 12:01 PM, Sean Dague wrote:
>> On 06/16/2014 12:44 PM, Ben Nemec wrote:
>>> On 06/16/2014 08:37 AM, Thierry Carrez wrote:
>>>> Sean Dague wrote:
>>>>> Hacking 0.9 series was released pretty late for Juno. The
>>>>> entire check queue was flooded this morning with requirements
>>>>> proposals failing pep8 because of it (so at 6am EST we were
>>>>> waiting 1.5 hrs for a check node).
>>>>>
>>>>> The previous soft policy with pep8 updates was that we set a 
>>>>> pep8 version basically release week, and changes stopped
>>>>> being done for style after first milestone.
>>>>>
>>>>> I think in the spirit of that we should revert the hacking 
>>>>> requirements update back to the 0.8 series for Juno. We're
>>>>> past milestone 1, so shouldn't be working on style only fixes
>>>>> at this point.
>>>>>
>>>>> Proposed review here -
>>>>> https://review.openstack.org/#/c/100231/
>>>>>
>>>>> I also think in future hacking major releases need to happen 
>>>>> within one week of release, or not at all for that series.
>>>
>>>> We may also have reached a size where changing style rules is
>>>> just too costly, whatever the moment in the cycle. I think it's
>>>> good that we have rules to enforce a minimum of common style,
>>>> but the added value of those extra rules is limited, while
>>>> their impact on the common gate grows as we add more projects.
>>>
>>> A few thoughts:
>>>
>>> 1) I disagree with the proposition that hacking updates can only 
>>> happen in the first week after release.  I get that there needs
>>> to be a cutoff, but I don't think one week is reasonable.  Even
>>> if we release in the first week, you're still going to be dealing
>>> with hacking updates for the rest of the cycle as projects adopt
>>> the new rules at their leisure.  I don't like retroactively
>>> applying milestone 1 as a cutoff either, although I could see
>>> making that the policy going forward.
>>>
>>> 2) Given that most of the changes involved in fixing the new
>>> failures are trivial, I think we should encourage combining the
>>> fixes into one commit.  We _really_ don't need separate commits
>>> to fix H305 and H307. This doesn't help much with the reviewer
>>> load, but it should reduce the gate load somewhat.  It violates
>>> the one change-one commit rule, but "A foolish consistency..."
> 
>> The challenge is that hacking updates are basically giant merge
>> conflict engines. If there is any significant amount of code
>> outstanding in a project, landing hacking only changes basically
>> means requiring much of the outstanding code to rebase.
> 
>> So it's actually expensive in a way that doesn't jump out
>> immediately. The cost of landing hacking isn't just the code of
>> reviewing the hacking patches, it's also the cost of the extra
>> roundtrips on outstanding patches.
> 
> If a project has that many violations of a new hacking rule then I'd
> say they should just leave it disabled.  It already happens and I'd
> rather have that than throw out a rule just because some projects
> haven't been following it.

That would be fine if the propose bot *also* proposed the tox.ini
ignores, which it does not.

So it pushes a largely by definition broken patch that consumes
resources, and will require a human to take it over. If a person did
this on a regular basis, we'd have a stern talking to them. Or at least
a light making fun of them.

It feels like robo auto propose should be limited to the class of things
where the patch is 99% sure to pass.

Which I think is really the crux of my distaste for hacking breaking
updates auto proposing to projects.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/0278097d/attachment.pgp>