Open Stack

On Wed, Feb 01, 2017 at 07:49:21AM -0800, Ihar Hrachyshka wrote:
> On Wed, Feb 1, 2017 at 7:42 AM, Armando M. <armamig at gmail.com> wrote:
> >
> >
> > On 1 February 2017 at 07:29, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> >>
> >> Hi all,
> >>
> >> lately I see the requirements bot proposing new rebases for its
> >> patches (and bumping existing patch sets from the gate queue) every
> >> second hour, at least for Neutron [1], which makes it impossible to
> >> land the patches, and which only makes gate pre-release situation
> >> worse. On top of that, the proposed rebases don't really add anything
> >> material to the sync patch, no new version changes and such.
> >>
> >> I think we had some guards against such behavior before, so I wonder
> >> if they were broken or removed lately? Any plans to fix that?
> >>
> >> It would be nice to be able to land the update before RC1 is cut off,
> >> but at this point, it does not seem realistic.
> >>
> >> [1] https://review.openstack.org/#/c/423645/
> >>
> >
> > Let's stop merging until the bot proposal change lands. That ought to stop
> > the spurious rebase!
> >
> > Hard times require hard measures!!
> 
> That's assuming it's triggered by neutron merges. It may as well be
> requirements merges that trigger rebases. Something that I believe
> requirements team will help us to understand.

So it's a combination of both.  The bot runs are triggered on merges to
openstack/requirements but the rebases are (clearly) due to the fact that
neutron has advanced in the mean time.

We knew this was a suboptimal part of the process but until your thread we
assumed it was wasting CPU/gate resources.  You've exposed the developer
cost and that elevates this in priority.

We processes a few requirements feature freeze excetpions which is what caused
the issue you highlight in that review.  I'll see what I can do about finding
someone to fix this before we release Ocata.

The "fix" will be to check if the bot run is a rebase *and* if the current
revision of the change is lacking a vote from jenkins.  Hmmm I guess we should
*also* check if the version in gerrit has +W and avoid the upload in that case
also.


Yours Tony.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170202/340fc6b1/attachment.pgp>