Hi Dave :) On 5 May 2015 at 10:37, Dave Walker <em...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
