Open Stack

Excerpts from Doug Hellmann's message of 2015-10-15 15:57:20 -0400:
> 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
> > >>> <prometheanfire at 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.

Looking back at the outline for that session, it's much more likely that
we'll postpone the discussion until Friday's meetup time.

http://mitakadesignsummit.sched.org/event/65564a6d98bb83d881b712fda033aaed#.ViAI0rSO820

Doug