Open Stack

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.

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
>