[openstack-dev] revert hacking to 0.8 series

Ben Nemec openstack at nemebean.com
Mon Jun 16 22:46:22 UTC 2014


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.

> 
> 
>>
>> 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
>>
>>
> 




More information about the OpenStack-dev mailing list