Open Stack

On Mon, Jun 16, 2014 at 2:33 PM, Sean Dague <sean at dague.net> wrote:

> On 06/16/2014 05:06 PM, Ben Nemec wrote:
> > On 06/16/2014 12:01 PM, Sean Dague wrote:
> >> On 06/16/2014 12:44 PM, 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.
> >>>
> >>> 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..."
> >
> >> The challenge is that hacking updates are basically giant merge
> >> conflict engines. If there is any significant amount of code
> >> outstanding in a project, landing hacking only changes basically
> >> means requiring much of the outstanding code to rebase.
> >
> >> So it's actually expensive in a way that doesn't jump out
> >> immediately. The cost of landing hacking isn't just the code of
> >> reviewing the hacking patches, it's also the cost of the extra
> >> roundtrips on outstanding patches.
> >
> > If a project has that many violations of a new hacking rule then I'd
> > say they should just leave it disabled.  It already happens and I'd
> > rather have that than throw out a rule just because some projects
> > haven't been following it.
>
> That would be fine if the propose bot *also* proposed the tox.ini
> ignores, which it does not.
>
> So it pushes a largely by definition broken patch that consumes
> resources, and will require a human to take it over. If a person did
> this on a regular basis, we'd have a stern talking to them. Or at least
> a light making fun of them.
>
> It feels like robo auto propose should be limited to the class of things
> where the patch is 99% sure to pass.
>

I feel the same way on this one, for some reason I was originally under the
impression that hacking had to manually be rolled out because of the
reasons above.


>
> Which I think is really the crux of my distaste for hacking breaking
> updates auto proposing to projects.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> _______________________________________________
> 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/b0587b46/attachment.html>