Excerpts from Matthew Thode's message of 2015-10-15 14:35:08 -0500:
> 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 :(
>
We're going to try to cover it in
http://mitakadesignsummit.sched.org/event/27c17a3c35d72997b372ddf4759fe1be#.ViAE67SO820
but we have a lot of other things to fit into that session so I want to
put this one last so we don't derail the other discussions.
Doug
__________________________________________________________________________
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
