On 28 February 2013 08:29, Sean Dague <sdague at linux.vnet.ibm.com> wrote: > In an ideal world I'd say a solution that pins everything to maximum known > working versions in the tree. Then a background set of jobs that tries > canary builds of new dependency versions (unpin them one at a time), and > reports success or fail (registering a bugs to either increase our cap, or > that component X doesn't work with the new cap) would be what we want. It's > pretty complicated, but given the level of infrastructure we currently > have, is something someone actually could build in the havana time frame. > The centralized dependency list would make life easier, but you could even > pull it off without that. > Approaching the problem from the other direction - would it be possible to have a gated pypi mirror? Sync to a staging area once per day/hour/whenever for external dependencies and run a gate when the sync is done to test whether it's safe to use the freshest update? Cheers, Kieran > Honestly, a big part of the fact that we even have this issue is our > testing is good enough that master can't really bitrot. On most projects > these sort of breaks would be sitting in the tree for weeks because it > worked fine on a developer's workstation and ci was stale in what it's base > image looked like. So kuddos for us having a system that's giving us new > and interesting problems to solve. :) > > > -Sean > > -- > Sean Dague > IBM Linux Technology Center > email: sdague at linux.vnet.ibm.com > alt-email: sldague at us.ibm.com > > > > ______________________________**_________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org> > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130228/0540c4c9/attachment-0001.html>