Open Stack

Hi Doug,

Doug Hellmann, 2018-03-14 23:42:
> We keep doing lots of infra-related work to make it "easy" to do
>  when it comes to
> managing dependencies.  There are three ways to address the issue
> with horizon and neutron, and none of them involve adding features
> to pbr.
> 
> 1. Things that are being used like libraries need to release like
>    libraries. Real releases. With appropriate version numbers. So
>    that other things that depend on them can express valid
> dependencies.
> 
> 2. Extract the relevant code into libraries and release *those*.
> 
> 3. Things that are not stable enough to be treated as a library
>    shouldn't be used that way. Move the things that use the
> application
>    code as library code back into the repo with the thing that they
>    are tied to but that we don't want to (or can't) treat like a
>    library.

What about the case where there is co-development of features across
repos ? One specific case I have in mind is the Neutron stadium where
we sometimes have features in neutron repo that are worked on as a pre-
requisite for things that will be done in a neutron-* or networking-*
project. Another is a case for instance where we need to add in project
X a tempest test to validate the resolution of a bug for which the fix
actually happened in project B (and where B is not a library).

My intuition is that it is not illegitimate to expect this kind of
development workflow to be feasible; but at the same time I read your
suggestion above as meaning that it belongs to the real of "things we
shouldn't be doing in the first place".  The only way I can reconcile
the two would be to conclude we should collapse all the module in
neutron-*/networking-* into neutron, but doing that would have quite a
lot of side effects (yes, this is an understatement).

-Thomas