On 10/15/2015 02:17 PM, Matt Riedemann wrote: > > > On 10/15/2015 2:10 PM, Matthew Thode wrote: >> On 10/15/2015 02:04 PM, Robert Collins wrote: >>> On 16 October 2015 at 08:01, Matthew Thode >>> <prometheanf...@gentoo.org> wrote: >>>> So, this is my perspective in packing liberty for Gentoo. >>>> >>>> We can have multiple versions of a package available to install, >>>> because >>>> of this we generally directly translate the valid dependency versions >>>> from requirements. >>> >>> Cool. >>> >>>> this >>>> oslo.concurrency>=2.3.0 # Apache-2.0 >>>> becomes this >>>> >=dev-python/oslo-concurrency-2.3.0[${PYTHON_USEDEP}] >>>> >>>> Now what happens when I package something from mitaka (2.7.0 in this >>>> case would be mitaka). It's undefined behaviour as far as I know. >>>> >>>> Basically, I can see no reason why the policy of caps changed from kilo >>>> to liberty, it was actually nice to package for liberty, I can see this >>>> going very bad very quick. >>> >>> They changed because it was causing huge trauma and multiple day long >>> gate wedges around release times. Covered in detail here - >>> http://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html >>> >>> >>>> Where are my caps? >>> >>> The known good versions of dependencies for liberty are >>> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/liberty >>> >>> >> That's good, does that represent an upper constraint for the lower >> constraint imposed by by the package? Why is this kept separate? >> Keeping it separate means that it's not trivial to merge them with >> what's in each package's requirements. > > I'm not sure I understand the first question but I believe that u-c is > automatically adjusted and if there is a conflict with the minimum > version required of a dependency then the cap is adjusted (or vice-versa). > > It's separate, at least in part, because the changes to > global-requirements are synced to all projects in the projects.txt file > in the requirements repo, which causes a bunch of churn to get those > changes approved in the registered projects and then released > appropriately. > > The global sync to the ecosystem isn't fun, I'll agree, but I do think > that thinks have been better since Juno/Kilo because (1) we don't allow > <= caps in g-r anymore (we were not allowing patch version updates which > wedged us several times) and (2) we're better about releasing things > with minor version updates per semver - whereas in the past the cats > were releasing on their own volition and picking the version they > thought was best, which creeped into having multiple versions that could > be acceptable across branches, and we'd have wedges those ways too. I > think a lot of that has been fixed by the openstack/releases repo so > that the cats now have to line up for the release of their library with > a centralized team. >
I'd agree with this, I still don't know what to cap things to. I need to figure out what the caps should be... It could be hard to sync across projects but like you say, most of that's gotten better since then. >> >>> You should be able to trivially pull those versions out and into your >>> liberty set of packages. >>> >>> Theres another iteration on this in discussion now, which has to do >>> with backwards compat *and testing of cap changes*, we'll be in the >>> backwards compat fishbowl session in Tokyo if you're interested. >>> >>> -Rob >>> >> >> I'll be at the fishbowl :D >> > Anyone have a sched link to that fishbowl, I can't find it :( -- Matthew Thode __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev