Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

3) We should start requiring specs for all new hacking rules to make
sure we have consensus (I think oslo-specs is the place for this).  2
+2's doesn't really accomplish that.  We also may need to raise the
bar for inclusion of new rules - while I agree with all of the new
ones added in hacking .9, I wonder if some of them are really necessary.

4) I don't think we're at a point where we should freeze hacking
completely, however.  The import grouping and long line wrapping
checks in particular are things that reviewers have to enforce today,
and that has a significant, if less well-defined, cost too.  If we're
really going to say those rules can't be enforced by hacking then we
need to remove them from our hacking guidelines and start the long
process of educating reviewers to stop requiring them.  I'd rather
just deal with the pain of adding them to hacking one time and never
have to think about them again.  I'm less convinced the other two that
were added in .9 are necessary, but in any case these are discussions
that should happen in spec reviews going forward.

5) We may want to come up with some way to globally disable pep8
checks we don't want to enforce, since we don't have any control over
that but probably don't want to just stop updating pep8.  That could
make the pain of these updates much less.

I could probably come up with a few more, but this is already too
wall-of-texty for my tastes. :-)

- -Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTnx7wAAoJEDehGd0Fy7uqoYAH/0KmxmR873Qn2Kti7LIEUNp4
1FJaBOX09ItxkkvyNRpcsIQu4fWycm60CckSOLfB7rgxgIjgsVkiZ9puE6oCmj2o
Lhe5DhjYA2ROu9h8i0vmzYDnAKeu/WuRGtgyLSElUXeuiLpSrBcEA/03GpkCGiAP
1muAkVgv2oxDDwsaLwL7MmFrlZ1MPTP97lAfsfHbwbsOM5YMuPrRz9PirgHPBtTV
59UyofCGEBTtJKmJRLzRDZyDwTux5xrrc/cefer5GFLQH0ZbxOU1HHFESyc5wFVJ
tI/3nPlbFpqCUtgmnQc8k3lX3d2H1Qr9UfCvYlJFTN1TmPmHmK378ioi81HoAVo=
=tqtf
-----END PGP SIGNATURE-----