Open Stack

I started an ethercalc to track this since we have patches from multiple 
people now: https://ethercalc.openstack.org/ml1qj9xrnyfg

If you're interested in pumping your commit stats feel free to take one 
of the projects that doesn't have a review listed and get that 
submitted. It would be great to have some non-cores do that so the cores 
can approve them. We've been following a single-approver model for this 
since all of the patches are basically the same.

If you do submit a patch to fix this, please add it to the ethercalc 
too. I've been marking merged patches in green to keep track of our 
progress.

Thanks.

On 5/13/19 12:40 PM, Ben Nemec wrote:
> 
> 
> On 5/13/19 12:23 PM, Ben Nemec wrote:
>> Nefarious cap bandits are running amok in the OpenStack community! 
>> Won't someone take a stand against these villainous headwear thieves?!
>>
>> Oh, sorry, just pasted the elevator pitch for my new novel. ;-)
>>
>> Actually, this email is to summarize the plan we came up with in the 
>> Oslo meeting this morning. Since we have a bunch of projects affected 
>> by the Bandit breakage I wanted to make sure we had a common fix so we 
>> don't have a bunch of slightly different approaches in each project. 
>> The plan we agreed on in the meeting was to push a two patch series to 
>> each repo - one to cap bandit <1.6.0 and one to uncap it with a 
>> !=1.6.0 exclusion. The first should be merged immediately to unblock 
>> ci, and the latter can be rechecked once bandit 1.6.1 releases to 
>> verify that it fixes the problem for us.
> 
> Oh, and since sphinx is also breaking the Oslo world, I guess we're 
> going to have to include the sphinx requirements fix in these first 
> patches: https://review.opendev.org/#/c/658857/
> 
> That's passing the requirements job so it should unblock us.
> 
> /me is off to squash some patches
> 
>>
>> We chose this approach instead of just tweaking the exclusion in 
>> tox.ini because it's not clear that the current behavior will continue 
>> once Bandit fixes the bug. Assuming they restore the old behavior, 
>> this should require the least churn in our repos and means we're still 
>> compatible with older versions that people may already have installed.
>>
>> I started pushing patches under 
>> https://review.opendev.org/#/q/topic:cap-bandit (which prompted the 
>> digression to start this email ;-) to implement this plan. This is 
>> mostly intended to be informational, but if you have any concerns with 
>> the plan above please do let us know immediately.
>>
>> Thanks.
>>
>> -Ben
>>
>