[Rdo-list] python-*client packaging

[Steven Hardy]

On Mon, Jun 02, 2014 at 09:46:42AM -0700, Dan Smith wrote:
> > What about the point that the CI runs on what gets uploaded to pypi
> > and therefore the random commits are not as thoroughly tested?
> 
> The commits are tested just like anything else, but projects that *use*
> the client don't gate on the new code until it is released. So, a commit
> to novaclient runs a full nova stack just like a nova patch would, and
> should have anything else that uses it (like neutron) run against it as
> well, which should prevent merging a patch against novaclient that
> breaks neutron.

Exactly, so by taking a random git version you run a greater risk of
regressions/interface changes breaking projects which depend on the client,
so it's essential you re-test every client-consuming project, which doesn't
happen as part of the *client gate run (but does indirectly after a
release, because client-consuming projects have their gates break).

Also it's worth pointing out that the gate coverage (unit tests and
functional tests via tempest scenario tests) for many *clients is not that
great, so relying on the gate check for the client patches is not a good
strategy IMO.

> It does happen that we occasionally merge a patch that was fine at one
> point, but races with another change in another project to create a
> problem once it's released. However, that breaks the world and everyone
> jumps on it immediately. Infrequent and short-lived.

It's true that major regressions normally get attention pretty quickly, but
more often what happens is the consuming projects, such as Heat, fix their
master to cope with the new client behavior to un-break their gate and move
on.  Again, this implies that by picking a random git version of a client,
you run the risk that various projects will just break in exciting ways.

FWIW, it's not that infrequent at all IME, heat regularly gets broken by
client releases.

Cheers,

Steve