Open Stack

On Jun 16, 2014 9:44 AM, "Ben Nemec" <openstack at nemebean.com> wrote:
>
> -----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).

This is a general issue with global requirements, the number of jobs we run
and the number of available nodes. Let's solve the general case.

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

I would rather just have more folks review hacking patches then add a specs
repo. A specs repo is overkill, IMHO, hacking doesn't have that many
patches per cycle. In general when adding a rule to hacking it has to
already be in HACKING.rst and/or needs a ML post.

> 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-----
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/7f260bc2/attachment.html>