Open Stack

 ---- On Fri, 19 Feb 2021 07:51:27 -0600 Brian Rosmaita <rosmaita.fossdev at gmail.com> wrote ----
 > On 2/17/21 7:49 PM, Ghanshyam Mann wrote:
 > >   ---- On Wed, 20 Jan 2021 16:45:19 -0600 Jeremy Stanley <fungi at yuggoth.org> wrote ----
 > >   > On 2021-01-20 07:26:05 +0000 (+0000), Lucian Petrut wrote:
 > >   > > For Windows related projects such as os-win and networking-hyperv,
 > >   > > we decided to keep the lower constraints job but remove indirect
 > >   > > dependencies from the lower-constraints.txt file.
 > >   > >
 > >   > > This made it much easier to maintain and it allows us to at least cover
 > >   > > direct dependencies. I suggest considering this approach instead of
 > >   > > completely dropping the lower constraints job, whenever possible.
 > >   > > Another option might be to make it non-voting while it’s getting fixed.
 > >   > [...]
 > >   >
 > >   > The fewer dependencies a project has, the easier this becomes. I'm
 > >   > not against projects continuing to do it if they can get it to work,
 > >   > but wouldn't want us to pressure folks to spend undue effort on it
 > >   > when they already have a lot more on their plates. I can understand
 > >   > where for projects with a very large set of direct dependencies this
 > >   > still has the problem that your stated minimums may conflict with
 > >   > (semi-circular) dependencies declared elsewhere in the transitive
 > >   > dependency set outside your lower-constraints.txt/requirements.txt
 > >   > file.
 > > 
 > > I tried with the direct deps with cinder, nova and placement by keeping only
 > > deps what we have in requirements.txt, test-requirements.txt, and  'extras' in setup.cfg.
 > > We need to get all those three to pass the requirement-check job as it checks for
 > > all those deps to be in lower-constraints.txt
 > > 
 > > - https://review.opendev.org/q/topic:%22l-c-direct-deps-only%22+(status:open%20OR%20status:merged)
 > > 
 > > Some nova test failing which might need some deps version bump but overall It seems direct deps work
 > > fine and removes a lot of deps from l-c file (77 from nova, 64 from cinder). With that testing, I am ok
 > > with that proposal now (as in my experience on community goals effort, I spent 50% of the time on
 > > fixing the indirect deps ).
 > > 
 > > I am summarizing the discussion and earlier proposal below, please let us know if that works fine for everyone
 > > and accordingly, we can take the next step to document this somewhere and project start working on this.
 > 
 > Thanks for all your work on this, Ghanshyam.
 > 
 >  > - Only keep direct deps in lower-constraints.txt
 > 
 > I think this makes sense in master as a sanity check that the 
 > requirements.txt minima haven't drifted out of date to the extent that 
 > they break unit tests.
 > 
 >  > - Remove the lower constraints testing from all stable branches.
 > 
 > I agree, there doesn't seem to be any point in this any more.
 > 
 > 
 > One question: A takeaway I had from the discussion is that the 
 > lower-constraints files aren't being used by packagers, etc., so there 
 > doesn't seem to be any point in trying to keep the specified versions as 
 > low as possible.  So I'm planning to update the cinder project 
 > deliverables requirements.txt and lower-constraints.txt files for the 
 > upcoming release to whatever pip freeze indicates is actually being used 
 > right after Milestone 3.  Are there any objections to this strategy?

As per the checks in TC meeting and ML discussion, it was found that only Debian 
checks lower-constraints and rest all packagers use upper constraints[1]

Are you suggesting making the latest Milestone 3 as a base for lower constraints and
in future, keep them as long as they work fine or every cycle you will update them to the latest
release (which is nothing but the upper-constraints right?)?

Maybe Thomas can answer your question if that works for Debian.

[1]- http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019877.html

-gmann

 > 
 > > 
 > > -gmann
 > > 
 > >   > --
 > >   > Jeremy Stanley
 > >   >
 > > 
 > 
 > 
 >