On 5/15/19 10:49 AM, Matthew Thode wrote:
If it helps, upper-constraints still has not been updated (and is -W'd)
I'm a little confused by this patch. We don't use upper-constraints for linters or this probably wouldn't have broken us. It looks like that is just updating a test file?
On 19-05-15 10:38:13, Ben Nemec wrote:
Yeah, I've just been relying on our cores to not merge the uncap patches before we're ready. I'm fine with marking them WIP too though.
On 5/15/19 7:55 AM, Moises Guimaraes de Medeiros wrote:
Doug, they pass now, and might fail once 1.6.1 is out and the behavior is not fixed, but that will probably need a recheck on a passed job. The -W would be just a reminder not to merge them by mistake.
Em qua, 15 de mai de 2019 às 14:52, Doug Hellmann <doug@doughellmann.com <mailto:doug@doughellmann.com>> escreveu:
Moises Guimaraes de Medeiros <moguimar@redhat.com <mailto:moguimar@redhat.com>> writes:
> Should uncap patches be -W until next bandit release?
I would expect them to fail the linter job until then, so I don't think that's strictly needed.
> > Em ter, 14 de mai de 2019 às 17:26, Doug Hellmann <doug@doughellmann.com <mailto:doug@doughellmann.com>> > escreveu: > >> Zane Bitter <zbitter@redhat.com <mailto:zbitter@redhat.com>> writes: >> >> > On 13/05/19 1: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. >> > >> > I take it that just blocking 1.6.0 in global-requirements isn't an >> > option? (Would it not work, or just break every project's requirements >> > job? I could live with the latter since they're broken anyway because of >> > the sphinx issue below...) >> >> Because bandit is a "linter" it is in the blacklist in the requirements >> repo, which means it is not constrained there. Projects are expected to >> manage the versions of linters they use, and roll forward when they are >> ready to deal with any new rules introduced by the linters (either by >> following or disabling them). >> >> So, no, unfortunately we can't do this globally through the requirements >> repo right now. >> >> -- >> Doug >> >> > > -- > > Moisés Guimarães > > Software Engineer > > Red Hat <https://www.redhat.com> > > <https://red.ht/sig>
-- Doug
--
Moisés Guimarães
Software Engineer
Red Hat <https://www.redhat.com>