Open Stack

If it helps, upper-constraints still has not been updated (and is -W'd)

https://review.opendev.org/658767

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

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190515/7abd8672/attachment.sig>