<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>Just an aside:</div>
<div> </div>
<div>One thing that I noticed is there seems to be a disconnect as to what "operators" see as technical debt and what developers see as technical debt. Personally, I see technical debt more inline with projects having xxx bug backlog, ___ feature while implemented
is done in a less than optimal way (nova resize for example), documentation around ____ is poor. Where developers see technical debt is what is preventing us from moving to python version 3, where are we missing/broken unit test coverage, this internal only
API is ____ and I want to refactor it.</div>
<div><br>
</div>
<div>To me moving from one version of python to another version of python is a feature – not technical debt. </div>
<div><br>
</div>
<div>I personally am hoping for a clear definition of what "stable" actually means. I am use to stable meaning no new features, just bug fixes. Having been bit by the recent keystone Icehouse.1 -> Icehouse.2 breaking everything AD, because of a UTF8 conversion
feature that blew up when it hit binary data. It apparent that some peoples definition of stable is different than others.</div>
<div><br>
</div>
<div>It would also be nice if it was possible to make a patch to a stable branch and have it be tagged as something that could be brought forward. Versus having to figure out where in master everything is (which could be radically different), then patching
that and then trying to get that back ported to a stable release. I know we (Godaddy) try to stay on stable releases and not run on trunk, I assume a majority of other operators do as well. </div>
<div>
<div>
<div>____________________________________________</div>
<div> </div>
<div>Kris Lindgren</div>
<div>Senior Linux Systems Engineer</div>
<div>GoDaddy, LLC.</div>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Roland Chan <<a href="mailto:roland@aptira.com">roland@aptira.com</a>><br>
<span style="font-weight:bold">Date: </span>Friday, November 14, 2014 at 1:22 PM<br>
<span style="font-weight:bold">To: </span>Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>><br>
<span style="font-weight:bold">Cc: </span>OpenStack Operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches<br>
</div>
<div><br>
</div>
<div>
<div>
<p dir="ltr"><br>
On 15/11/2014 1:46 am, "Jeremy Stanley" <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br>
> the truth is that work on these projects is entirely<br>
> voluntary and we have no effective way to enforce a decree like<br>
> that.</p>
<p dir="ltr">I don't think that's entirely correct. A large, potentially overwhelming, majority of committers seem to be paid to work on OpenStack. Proof of this is that we manage to commit to and deliver a large number of features according to a rigorous schedule.</p>
<p dir="ltr">I do agree that we do not have a way to enforce this but the community could find one, I'm sure. The community is bound by its own rules and needs to decide whether retiring technical debt is a priority. If it is, then a means of commitment to
that goal must be established. That will slow down feature development since the resource pool is finite, and that is no bad thing.</p>
<p dir="ltr">> Also, because English is a terribly, terribly nuanced language, I<br>
> actually read that "may" as granting permission, not stating an<br>
> optional imperative in the RFC sense.</p>
<p dir="ltr">And that is correct but it isn't desirable, at least not to me.</p>
<p dir="ltr">Roland</p>
</div>
</div>
</span>
</body>
</html>