Open Stack

On Mon, Jun 16, 2014 at 2:56 PM, Doug Hellmann <doug.hellmann at dreamhost.com>
wrote:

> On Mon, Jun 16, 2014 at 2:23 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> >
> > 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.
>
> You wouldn't need a new repo. Hacking is part of the Oslo program, so
> you would use oslo-specs just like the other Oslo projects.
>
> The process you describe is what we've done historically, but as we
> standardize on specs repos we will want to eventually reconsider it.
> If the point of posting to the mailing list is to encourage
> discussion, then it seems like that step could be replaced with a
> spec.
>

Perhaps, I still am not sure how that really helps.


>
> Doug
>
> >
> >> 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
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> 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/7bfc4be7/attachment.html>