On 08/11/2016 07:56 PM, Tony Breeds wrote:
On Thu, Aug 11, 2016 at 09:13:12AM +0200, Andreas Jaeger wrote:
On 2016-08-10 23:06, Sean Dague wrote:
Based on reading some logs, it looks like requirements updates are
getting regenerated on every requirements land for all open patches,
even if they aren't impacted by it -
https://review.openstack.org/#/c/351991/
patch 10,11,12 in that series are just rebases, all happening within a
couple of hours.
With the check queue at ... 505 changes as of this email, this is
definitely adding some extra load to the system.
It would be a great optimization for someone to look at the script -
https://github.com/openstack-infra/project-config/blob/ab89ab40ed74db306ce10e36341d39f23231f012/jenkins/scripts/propose_update.sh
and make it so that if the commit did not change, don't push a rebased
review.
Good idea!
One thing to keep in mind: You want to rebase if there's a merge conflict...
What about adding a check and only rebasing if and only if the chnage in
question has a -1 from Jenkins?
That'd mean that in-flight reviews don't get rebased but we *do* rebase if
we're in merge conflict.
The downside to this is we'll be doing *more* gerrit queries but that's
probably ok.
That seems like a further optimization. Honestly, I would rarely expect
these to be in merge conflict, and at worse, they would be so until the
next requirements push.
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
