Open Stack

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>
>