Re: [openstack-dev] [pbr] regular releases, and path to 1.0
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. -- Jeremy Stanley __ 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
Re: [openstack-dev] [pbr] regular releases, and path to 1.0
On 4 May 2015 at 23:01, Jeremy Stanley fu...@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 __ 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
Re: [openstack-dev] [pbr] regular releases, and path to 1.0
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
Re: [openstack-dev] [pbr] regular releases, and path to 1.0
+1 to call the current master as 1.0 +1 to more frequent releases (not sure if it should be every monday though!) -- dims On Mon, May 4, 2015 at 3:53 PM, Robert Collins robe...@robertcollins.net wrote: Hi, I'd like to talk about how often we can and should release pbr, and what criteria we should use for 1.0. tl;dr: release weekly [outside of organisation-wide-freezes], do a 1.0 immediately. pbr, like all our libraries affects everything when its released, but unlike everything else in oslo, it is an open ended setup_requires dependency. It's like this because of https://github.com/pypa/pip/issues/2666 - when setuptools encounters a setup_requires constraint that conflicts with an already installed version, it just gives up. Until thats fixed, if we express pbr constraints like pbr 1.0 we'll cause everything that has previously released to hard-fail to install as soon as anything in the environment has pulled in a pbr that doesn't match the constraint. This will get better once we have pip handle setup_requires with more scaffolding... we can in principle get to the point where we can version the pbr setup_requires dependencies. However - thats future, and indefinite at this point. So, for pbr we need to have wide open constraints in setup_requires, and it must be in setup_requires (otherwise pip can't build egg info at all and thus can't probe the install_requires dependencies). The consequence of this is that pbr has to be ultra conservative - we're not allowed any deliberate API breaks for the indefinite future, and even once the tooling supports it we'd have to wait for all the current releases of things that couldn't be capped to semantic versioning limits, to be unsupported. So - we're at least 18 months away from any possible future where API breaks - a 2.0 - are possible without widespread headaches. In light of this, I'd like to make two somewhat related proposals. Firstly, I'd like to just call the current master 1.0: its stable, we're supporting it, its not going anywhere rash, it has its core feature set. Those are the characteristics of 1.0 in most projects :). Its not a big splashy 1.0 but who cares..., and there's more we need, but thats what 1.x is for. Secondly, I'd like to release every Monday (assuming no pending reverts): I'd like to acknowledge the reality that we have approximately zero real world testing of master - we're heavily dependent on our functional tests. The only two reasons to wait for releasing are a) to get more testing, and we don't get that, and b) to let -core notice mistakes and back things out. Waiting to release once an improvement is in master just delays giving the benefits to our users. -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 -- Davanum Srinivas :: https://twitter.com/dims __ 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
Re: [openstack-dev] [pbr] regular releases, and path to 1.0
On 5 May 2015 at 08:04, Clark Boylan cboy...@sapwetik.org wrote: On Mon, May 4, 2015, at 12:53 PM, Robert Collins wrote: I don't understand what you mean by zero real world testing of master. We test that pbr can make sdists and install packages on every change to master before merging those changes. That is the majority of what pbr does for us. We can definitely add more testing of the other bits (running tests, building docs, etc), but I don't think it is fair to say we have approximately zero real world testing of master. We do exhaustive tests that work across a large set of openstack projects. Thats not at all the same as real world tests. We don't know that it works on Arch linux, for instance. Or windows. We don't know that it works when someone has a GSM modem and flaky internet. As we identify common failure modes or things we want to support we add them and thats entirely appropriate, but its never going to be the same degree of pathology that end users can bring. -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
Re: [openstack-dev] [pbr] regular releases, and path to 1.0
On 05/04/2015 03:53 PM, Robert Collins wrote: Hi, I'd like to talk about how often we can and should release pbr, and what criteria we should use for 1.0. tl;dr: release weekly [outside of organisation-wide-freezes], do a 1.0 immediately. pbr, like all our libraries affects everything when its released, but unlike everything else in oslo, it is an open ended setup_requires dependency. It's like this because of https://github.com/pypa/pip/issues/2666 - when setuptools encounters a setup_requires constraint that conflicts with an already installed version, it just gives up. Until thats fixed, if we express pbr constraints like pbr 1.0 we'll cause everything that has previously released to hard-fail to install as soon as anything in the environment has pulled in a pbr that doesn't match the constraint. This will get better once we have pip handle setup_requires with more scaffolding... we can in principle get to the point where we can version the pbr setup_requires dependencies. However - thats future, and indefinite at this point. So, for pbr we need to have wide open constraints in setup_requires, and it must be in setup_requires (otherwise pip can't build egg info at all and thus can't probe the install_requires dependencies). The consequence of this is that pbr has to be ultra conservative - we're not allowed any deliberate API breaks for the indefinite future, and even once the tooling supports it we'd have to wait for all the current releases of things that couldn't be capped to semantic versioning limits, to be unsupported. So - we're at least 18 months away from any possible future where API breaks - a 2.0 - are possible without widespread headaches. In light of this, I'd like to make two somewhat related proposals. Firstly, I'd like to just call the current master 1.0: its stable, we're supporting it, its not going anywhere rash, it has its core feature set. Those are the characteristics of 1.0 in most projects :). Its not a big splashy 1.0 but who cares..., and there's more we need, but thats what 1.x is for. WFM Secondly, I'd like to release every Monday (assuming no pending reverts): I'd like to acknowledge the reality that we have approximately zero real world testing of master - we're heavily dependent on our functional tests. The only two reasons to wait for releasing are a) to get more testing, and we don't get that, and b) to let -core notice mistakes and back things out. Waiting to release once an improvement is in master just delays giving the benefits to our users. I'm fine with that in principle - I tend to release personal libraries pretty much as soon as something interesting hits them. I have no personal fear of high release counts. I'm not sure I 100% agree with every Monday ... I think we should be flexible enough at this point to just release actively. But I don't feel strongly about it. Monty __ 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
Re: [openstack-dev] [pbr] regular releases, and path to 1.0
On 05/04/2015 04:15 PM, Robert Collins wrote: On 5 May 2015 at 08:12, Monty Taylor mord...@inaugust.com wrote: On 05/04/2015 03:53 PM, Robert Collins wrote: I'm fine with that in principle - I tend to release personal libraries pretty much as soon as something interesting hits them. I have no personal fear of high release counts. I'm not sure I 100% agree with every Monday ... I think we should be flexible enough at this point to just release actively. But I don't feel strongly about it. Perhaps: - no more frequently than weekly in the absence of brown-bag-fixups - to allow pbr-core to look for 'oh WAT no we're not doing that' things slipping in due to review team de-sync. - Early in the week rather than late - to avoid surprises on weekends ++ __ 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
Re: [openstack-dev] [pbr] regular releases, and path to 1.0
On Mon, May 4, 2015, at 12:53 PM, Robert Collins wrote: Hi, I'd like to talk about how often we can and should release pbr, and what criteria we should use for 1.0. tl;dr: release weekly [outside of organisation-wide-freezes], do a 1.0 immediately. pbr, like all our libraries affects everything when its released, but unlike everything else in oslo, it is an open ended setup_requires dependency. It's like this because of https://github.com/pypa/pip/issues/2666 - when setuptools encounters a setup_requires constraint that conflicts with an already installed version, it just gives up. Until thats fixed, if we express pbr constraints like pbr 1.0 we'll cause everything that has previously released to hard-fail to install as soon as anything in the environment has pulled in a pbr that doesn't match the constraint. This will get better once we have pip handle setup_requires with more scaffolding... we can in principle get to the point where we can version the pbr setup_requires dependencies. However - thats future, and indefinite at this point. So, for pbr we need to have wide open constraints in setup_requires, and it must be in setup_requires (otherwise pip can't build egg info at all and thus can't probe the install_requires dependencies). The consequence of this is that pbr has to be ultra conservative - we're not allowed any deliberate API breaks for the indefinite future, and even once the tooling supports it we'd have to wait for all the current releases of things that couldn't be capped to semantic versioning limits, to be unsupported. So - we're at least 18 months away from any possible future where API breaks - a 2.0 - are possible without widespread headaches. In light of this, I'd like to make two somewhat related proposals. Firstly, I'd like to just call the current master 1.0: its stable, we're supporting it, its not going anywhere rash, it has its core feature set. Those are the characteristics of 1.0 in most projects :). Its not a big splashy 1.0 but who cares..., and there's more we need, but thats what 1.x is for. Sounds good. Secondly, I'd like to release every Monday (assuming no pending reverts): I'd like to acknowledge the reality that we have approximately zero real world testing of master - we're heavily dependent on our functional tests. The only two reasons to wait for releasing are a) to get more testing, and we don't get that, and b) to let -core notice mistakes and back things out. Waiting to release once an improvement is in master just delays giving the benefits to our users. I don't understand what you mean by zero real world testing of master. We test that pbr can make sdists and install packages on every change to master before merging those changes. That is the majority of what pbr does for us. We can definitely add more testing of the other bits (running tests, building docs, etc), but I don't think it is fair to say we have approximately zero real world testing of master. Clark __ 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
Re: [openstack-dev] [pbr] regular releases, and path to 1.0
On 5 May 2015 at 08:12, Monty Taylor mord...@inaugust.com wrote: On 05/04/2015 03:53 PM, Robert Collins wrote: I'm fine with that in principle - I tend to release personal libraries pretty much as soon as something interesting hits them. I have no personal fear of high release counts. I'm not sure I 100% agree with every Monday ... I think we should be flexible enough at this point to just release actively. But I don't feel strongly about it. Perhaps: - no more frequently than weekly in the absence of brown-bag-fixups - to allow pbr-core to look for 'oh WAT no we're not doing that' things slipping in due to review team de-sync. - Early in the week rather than late - to avoid surprises on weekends -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
[openstack-dev] [pbr] regular releases, and path to 1.0
Hi, I'd like to talk about how often we can and should release pbr, and what criteria we should use for 1.0. tl;dr: release weekly [outside of organisation-wide-freezes], do a 1.0 immediately. pbr, like all our libraries affects everything when its released, but unlike everything else in oslo, it is an open ended setup_requires dependency. It's like this because of https://github.com/pypa/pip/issues/2666 - when setuptools encounters a setup_requires constraint that conflicts with an already installed version, it just gives up. Until thats fixed, if we express pbr constraints like pbr 1.0 we'll cause everything that has previously released to hard-fail to install as soon as anything in the environment has pulled in a pbr that doesn't match the constraint. This will get better once we have pip handle setup_requires with more scaffolding... we can in principle get to the point where we can version the pbr setup_requires dependencies. However - thats future, and indefinite at this point. So, for pbr we need to have wide open constraints in setup_requires, and it must be in setup_requires (otherwise pip can't build egg info at all and thus can't probe the install_requires dependencies). The consequence of this is that pbr has to be ultra conservative - we're not allowed any deliberate API breaks for the indefinite future, and even once the tooling supports it we'd have to wait for all the current releases of things that couldn't be capped to semantic versioning limits, to be unsupported. So - we're at least 18 months away from any possible future where API breaks - a 2.0 - are possible without widespread headaches. In light of this, I'd like to make two somewhat related proposals. Firstly, I'd like to just call the current master 1.0: its stable, we're supporting it, its not going anywhere rash, it has its core feature set. Those are the characteristics of 1.0 in most projects :). Its not a big splashy 1.0 but who cares..., and there's more we need, but thats what 1.x is for. Secondly, I'd like to release every Monday (assuming no pending reverts): I'd like to acknowledge the reality that we have approximately zero real world testing of master - we're heavily dependent on our functional tests. The only two reasons to wait for releasing are a) to get more testing, and we don't get that, and b) to let -core notice mistakes and back things out. Waiting to release once an improvement is in master just delays giving the benefits to our users. -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
