Just an aside: 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.
To me moving from one version of python to another version of python is a feature - not technical debt. 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. 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. ____________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. From: Roland Chan <[email protected]<mailto:[email protected]>> Date: Friday, November 14, 2014 at 1:22 PM To: Jeremy Stanley <[email protected]<mailto:[email protected]>> Cc: OpenStack Operators <[email protected]<mailto:[email protected]>> Subject: Re: [Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches On 15/11/2014 1:46 am, "Jeremy Stanley" <[email protected]<mailto:[email protected]>> wrote: > the truth is that work on these projects is entirely > voluntary and we have no effective way to enforce a decree like > that. 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. 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. > Also, because English is a terribly, terribly nuanced language, I > actually read that "may" as granting permission, not stating an > optional imperative in the RFC sense. And that is correct but it isn't desirable, at least not to me. Roland
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
