Open Stack

On 06/16/2014 05:46 PM, Ben Nemec wrote:
> On 06/16/2014 04:46 PM, Joe Gordon wrote:
>> On Mon, Jun 16, 2014 at 2:33 PM, Sean Dague <sean at dague.net> wrote:
>>
>>> 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.
>>>
>>
>> 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.
> 
> I wonder if we should just make future hacking checks opt-in.  Normally
> I'd be opposed to that because in general people ignore opt-ins, but we
> seem to have enough people using style changes as low-hanging-fruit to
> get started that it might work in this case.

Whoops, forgot to credit Angus for the suggestion:
http://lists.openstack.org/pipermail/openstack-dev/2014-June/037877.html

> 
>>
>>
>>>
>>> Which I think is really the crux of my distaste for hacking breaking
>>> updates auto proposing to projects.
>>>
>>>         -Sean
>>>
>>> --
>>> Sean Dague
>>> http://dague.net
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>