Open Stack

On 5/15/19 10:49 AM, Matthew Thode wrote:
> If it helps, upper-constraints still has not been updated (and is -W'd)
> 
> https://review.opendev.org/658767

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 at doughellmann.com
>>> <mailto:doug at doughellmann.com>> escreveu:
>>>
>>>      Moises Guimaraes de Medeiros <moguimar at redhat.com
>>>      <mailto:moguimar at 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 at doughellmann.com <mailto:doug at doughellmann.com>>
>>>       > escreveu:
>>>       >
>>>       >> Zane Bitter <zbitter at redhat.com <mailto:zbitter at 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>
>>>
>>> <https://red.ht/sig>
>>>
>>
>