Open Stack

Hi Dave :)

On 5 May 2015 at 10:37, Dave Walker <email at daviey.com> wrote:
...
> Hey,
>
> As someone that did track master PBR Master for internal cross-project
> builds during the SemanticVersioning ping-pong, I have to agree that
> having a core tool that should be pretty static in feature deliverable
> be a regular blocker and instigator of build fails is a real pain.

Yup.

> I am not sure that weekly builds provide much in the way of value,
> depending on the consumer of the library.  The release cadence would
> be too short to really get value out of time base releases.  Is it
> expected to assist openstack-infra in being able to plan upgrading?  I
> can't see it helping distros or other vendors building derived
> versions of OpenStack?  Would this mean that OpenStack projects would
> have to start caring about PBR, or can they expected the core
> pipelines to continue to work without knowledge of PBR's releases?
> What version(s) would stable/* be expected to use?

The point isn't weekly builds, its not keeping inventory for extended
periods. pbr is only consumed via releases, and fixes to it tend to be
of the 'unbreak my workflow' sort - so fairly important to get them
out to users. As per the discussion about the inability to use
versioned dependencies, *all branches of OpenStack will use the latest
release of pbr always*. We simply cannot do stable release branches or
anything like that for pbr, because of setup_requires - see my first
email in this thread for the details. Thats a constraint, not a goal,
and it will be at least 18months before that constraint *can* be
lifted. Whether we should lift it isn't worth thinking about in the
mean time IMO - it will eventually get lifted because bugs will be
fixed, and we can discuss then whether it makes sense to start using
versioned dependencies on pbr.

> For sake of argument, what does weekly provide that monthly doesn't?
> Or in the opposite direction - why would each commit not be treated as
> a release?

As I said in my reply to Monty, we need some time for reviewers to
catch things that got in by mistake. The set of reviewers for pbr
includes all of oslo, not all of whom are familiar with the
intricacies of the Python packaging ecosystem and the constraints that
places on things. From time to time things merge that are fine python
code but not fine in the larger picture. So, that takes care of 'why
not make each commit a release'. As for monthly - why value does
holding an improvement back for 3 more weeks offer, assuming a week is
enough time for interested reviewers to cast an eye over recent
commits? Its obviously a dial, and I think the place to set it is
where the pbr reviewers are comfortable, which based on the thread so
far seems to be 'a week would be ok' - the consequence of a given
setting is that anyone interested in catching the occasional mistake
needs to review trunk changes no less than $setting.

> As a consumer of PBR, I stopped tracking master because I was
> frustrated rebasing, and I had low confidence the next rebase wouldn't
> break my entire pipeline in hidden or subtle ways.
>
> The last change I made to PBR took 4 months to get approved, just
> idling as unreviewed.  There is *nothing* more demotivating having a
> changeset blocked in this status, particularly when it is a simplistic
> change that is forcing you to use a derived version for internal usage
> causing additional cost of rebasing.  So, what is happening with the
> project now to make reviews happen soon enough to make frequent
> time-based release useful?

So there are a couple of related things here. Firstly, I feel your
pain. It sucks to have that happen. We don't have a good systemic
answer in OpenStack for this issue yet, and it affects nearly every
project. There are 10 or so reviewers with +A access to pbr changes. I
don't know why your change sat idle so long -
https://review.openstack.org/#/c/142144/ is the review I believe. Only
two of those 10 reviewers reviewed your patch, and indeed most of the
time it was sitting idle.

As to whats happening, we've finally gotten the year long semver stuff
out the door, which removes the ambiguity over master/0.10, and at
least at the moment I see a bunch of important feature work being done
around the ecosystem (in pip, and soon in setuptools and wheel and
pbr) to get what we need to address the CI fragility issues in a
system way. I find having a regular cadence for releases - we do
weekly releases in tripleo too - helps ensure that someone is looking
at the project each week. So - examining pbr to see if a release is
needed on a weekly basis should make the gap between reviews be
clamped at a week, which is a good thing for patches like that patch
of yours.

> Perhaps it would be useful to spell out some of the API breaking
> changes you are planning?

There are non planned.

>  It feels to me that PBR should be pretty
> static in the near term... I am not convinced that frequent releases
> make API breaking changes easier, as I am not sure a core library like
> PBR can just support 1.0 and n-1 - so would each release keep support
> for pbr's major and minor?

Since this seems to have been lost in the thread somewhere.

For the indefinite future pbr cannot ever ever ever ever break API
compatibility. We cannot issue stable versions or point releases. And
this is all due to setup_requires and how that works, and other bugs
in the ecosystem.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud