Excerpts from Tony Breeds's message of 2017-02-01 21:18:54 +1100: > On Wed, Jan 18, 2017 at 04:34:56PM -0500, Doug Hellmann wrote: > > When I tried to merge the upper-constraints updates for the library > > releases we did today, I ran into quite a lot of merge conflicts > > with the Oslo libraries. I'm exploring options for reducing the > > likelihood that those sorts of conflicts will occur with a few > > patches that change how we generate the constraints list. > > Dirk's been doing a great job of dealing with that and there are scripts to > take the ones generated from the bot and make single series from them n deep. > That's not very sustainable though. > > <snip> > > > The final option uses a SHA1 hash of the name as the sort key. It > > wouldn't be easy for a human to update the file by hand, but we > > could make a tool that does. I don't know how often that case comes > > up, so I don't know how important it is. See > > https://review.openstack.org/422245 and https://review.openstack.org/422246 > > for the sample output. > > Thanks Doug. I like this option. > > We don't need to add a tool as the docs describe how to do this already, which > basically boils down to run the tool you're patching. > > If that doesn't happen (which is common) the next daily update will just move > it to the new right place. > > I think we should do this early after we branch requirements > > Yours Tony.
While debugging the issues, although we learned that we're less likely to have collisions by changing the order, it's not going to be sufficient to deal with the problem posed when we have an Oslo release set. Zuul is limited to managing 6 "unrelated" patches when merging, so when we have more than 6 patches trying to merge it will throw an error that looks like a conflict, even though there isn't one. We discussed (on IRC) a couple of options: One is to do away with the proposals as part of the release jobs, and rely on the daily update. I'm not sure I like that, because it means if the update fails any tests we aren't introducing new versions of our libraries quickly. Debugging that class of failure is a job we've had a hard time recruiting people to help with, so while the current team has been doing a great job staying on top of it, I worry about what will happen when they get tired of doing it. We did also discuss changing the frequency of the automatic updates, but I think I was talked out of that on the grounds that it takes us a day to get the patch reviewed and merged anyway so running it more often would introduce delays because we would lose review votes. Another option was to have the release bot continually propose updates to the same patch, like we do with the global requirements sync job. On any given day, that's going to cause a bunch of resets on the patch, until we merge it. That will be particularly annoying if we release something while the patch is in the gate queue ready to be merged, but even in the check queue it will "waste" test nodes on each reset. The third option suggested was to submit the updates in a series. That allows us to merge them one at a time, and avoids the limit-of-6 issue because the patches are all related in a series. If something fails, we can remove it from the series by hand and debug it separately. I've put this topic on the etherpad for the stable/requirements/release team meetup at the PTG. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev