Open Stack

On 4 May 2015 at 23:01, Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2015-05-05 07:53:20 +1200 (+1200), Robert Collins wrote:
> [...]
>> release weekly
> [...]
>
> I'm fine with releasing weekly when there's something to release,
> but as PBR is somewhat stabilized and relatively tightly scoped I
> _hope_ that we get to the point where we don't have bugs or new
> features in PBR on a weekly basis.
>
> Cool with the rest of the proposal too.

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.

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?

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 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?

Perhaps it would be useful to spell out some of the API breaking
changes you are planning?  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?

(PS. I really like PBR)

--
Kind Regards,
Dave Walker