Open Stack

On Mon, Jun 16, 2014 at 2:54 PM, Angus Salkeld <angus.salkeld at rackspace.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 17/06/14 02:46, 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.
>
> Can't we move to a mode of enabling rules instead of ignoring them?
> If we did this in tox.ini then it wouldn't matter when you release
> hacking.
>
> [hacking]
> errors = H306,...
> ignore = H101
>
> So if you upgraded hacking you would not get the new checks generating
> errors, but only warnings.
>

This is out side the scope of hacking in and in the domain of the flake8
project, although we can easily contribute upstream to it.

As for warnings, I assume you mean we log the issue but don't gate on it, I
don't think anyone would pay attention to them, so not sure what the value
is.


>
> I guess the list of rules to error on would get big, but maybe we could
> have
> some short cuts (H3*,H2*)?
>
> At least the projects are a bit more in control of what rule they add.


> - -Angus
>
> >
> > 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
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTn2eqAAoJEFrDYBLxZjWo9dkIAJ55WTdVZgIHEFJGp+7Px8jC
> FxsBzRvDKeDTN6ONXUtE82G10ru6UR0HNndfhgbdEVQSazdcavbd/Q0AG+tmDyaE
> 7PBUpJ3bVIQVpJQ9tz/Xo4dqvsZhsOZBo28iLJyShU+VYy05I16WCGpsS0NUlD95
> ND78vjwUCNnjbzkOgBjt6V0QsuWpEZynIR6PfRkUJaaT+gFtrhAG7n4aQmgYnJri
> 9huTnEjyyg9KldlinxLxVP9nk2uVoKD7sfDAvREAjstFeRK4tVcdspB6xxPkfTKA
> RDAG1tGT0yvD3VtgqajFlJvImUyV7YN3/zXyXxKeb0301ouWpFeyiSZ1jqsK6Nc=
> =/Tmf
> -----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/3b61bfd0/attachment.html>