<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 2:04 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We had a process track session about bringing in upstream continuous<br>


deployment for openstack.<br>
<a href="https://etherpad.openstack.org/HavanaContinuousDeployment" target="_blank">https://etherpad.openstack.org/HavanaContinuousDeployment</a><br>
<br>
I suspect that while the session was good with both deployer and<br>
distributor attendees, we need to do more to make it happen, as it<br>
impinges on review / testing / backwards compat requirements for every<br>
project.<br>
<br>
Note that CD doesn't require no-downtime deployments, CD is about<br>
being able to adopt *any arbitrary revision of trunk* at *any point in<br>
time*. The engineering required to do deployments without disruption<br>
is beneficial to both CD and per-release deployments.<br>
<br>
Here are the key takeaways we came up with:<br>
 * No more big landings [except the purely mechanical]. Set a hard<br>
limit - maybe 500 lines of diff. Big landings are more risky per line<br>
of diff than small ones due to reviewer cognitive overhead - reviewers<br>
get non-linearly less effective the larger the review.<br></blockquote><div><br></div><div style>While I like this one, it sounds very hard to enforce in reality. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
 * CD can be done many ways; we need to gate the *specific* ways that<br>
upstream adopts, as soon as possible. Thats a -infra thing, and there<br>
are already discussions on it. We don't need to support *every<br>
possible config for CD*. Organisations interested in a particular<br>
configuration(s) will need to contribute resources to permit<br>
gate-quality checks of those configurations.<br>
<br>
 * No more cramming: when a freeze is happening, anything that is<br>
'land this for the release' has to be pushed back on -really hard-. If<br>
its not ready, it's not ready.<br></blockquote><div><br></div><div style>Has this been an issue recently? I thought we were getting better with this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
 * -never- choose to break something that is neither experimental nor<br>
deprecated since the last release. If an accident happens, correct it<br>
as quickly as possible.<br>
<br>
 * Land features disabled by default. Such disabled features are<br>
experimental and we don't need to be so careful - we can in fact<br>
remove them entirely if they turn out to be bad idea - when they<br>
become supported (individual teams can define this we think) they<br>
can't be broken again though: they are now part of the product.<br></blockquote><div><br></div><div style>This touches on a bigger issue, what is experimental and what is not.  Currently we don't do a good job of differentiating the two.  I think we first need to flesh out what it means to be experimental for users and for development.</div>

<div style> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
 * 'To break' means just that - it could be an exception, it could be<br>
a massive jump in DB utilisation, or latency. Whatever our criteria<br>
are for 'fit for use', breaking something stops it being fit for use<br>
in *existing deployed environments*.<br>
<br>
<br>
How do we get all this into place : I can update wiki pages etc, but<br>
is any more agreement needed? Should the TC eyeball it?<br>
<br>
-Rob<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Cloud Services<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>