On 13 April 2015 at 12:53, Monty Taylor <mord...@inaugust.com> wrote:
> What we have in the gate is the thing that produces the artifacts that > someone installing using the pip tool would get. Shipping anything with > those artifacts other that a direct communication of what we tested is > just mean to our end users. Actually its not. What we test is point in time. At 2:45 UTC on Monday installing this git ref of nova worked. Noone can reconstruct that today. I entirely agree with the sentiment you're expressing, but we're not delivering that sentiment today. We need to balance the inability to atomically update things - which forces a degree of freedom on install_requires - with being able to give someone the same install that we tested. That is the fundamental tension that we're not handling well, nor have I seen a proposal to tackle it so far. I'll have to spend some time noodling on this, but one of the clear constraints is that install_requires cannot both be: - flexible enough to permit us to upgrade requirements across many git based packages [because we could do coordinated releases of sdists to approximate atomic bulk changes] - tight enough enough to give the next person trying to run that ref of the package the same things we installed in CI. -> I think we need something other than install_requires ... > I disagree that anything is broken for us that is not caused by our > inability to remember that distro packaging concerns are not the same as > our concerns, and that the mechanism already exists for distro pacakgers > to do what they want. Furthermore, it is caused by an insistence that we > need to keep versions "open" for some ephemeral reason such as "upstream > might release a bug fix" Since we all know that "if it's not tested, > it's broken" - any changes to upstream software should be considered > broken until proven otherwise. History over the last 5 years has shown > this to be accurate more than the other thing. This seems like a strong argument for really being able to reconstruct what was in CI. > If we pin the stable branches with hard pins of direct and indirect > dependencies, we can have our stable branch artifacts be installable. > Thats awesome. IF there is a bugfix release or a security update to a > dependent library - someone can propose it. Otherwise, the stable > release should not be moving. Can we do that in stable branches? We've still got the problem of bumping dependencies across multiple packages. -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
