[Product] FW: [openstack-dev] Avoiding regression in project governance

Roland Chan roland at aptira.com
Tue Mar 17 12:24:09 UTC 2015


There's a fair bit of merit in the argument that the concept of production
ready is very hard to define and harder to enforce, especially as the code
base grows larger.

Do we have a team view on this?

Roland @ Aptira from mobile.
Ph: +61 4 28 28 48 58

On 17/03/2015 12:27 PM, "Rochelle Grober" <rochelle.grober at huawei.com>
wrote:

> Folks, I just wanted to highlight this message from the project governance
> thread.
> (link to full thread here:
> http://lists.openstack.org/pipermail/openstack-dev/2015-March/058689.html
>
> I think we need to review this thread and perhaps develop a team response?
>
> Or, maybe some of you want to comment on it?
>
> --Rocky
>
> -----Original Message-----
> From: Ed Leafe [mailto:ed at leafe.com]
> Sent: Wednesday, March 11, 2015 15:59
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Avoiding regression in project governance
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/11/2015 02:40 PM, Jeremy Stanley wrote:
> >> I think we can make this work. Assuming more than N (to my mind >
> >> > 5 or so) deployments report they are using project X, we can say
> >> > that this is used in production/POC/... and the number of
> >> > nodes/hypervisors/etc.
> >> >
> >> > This makes it concrete and anonymous to avoid the fishing queries.
> >> > It also allows our community to enter what they are doing in one
> >> > place rather than answering multiple surveys. I am keen to avoid
> >> > generic queries such as "How many hypervisors are installed for
> >> > public clouds using Xen" but if we have an agreement that >5
> >> > avoids company identification, I feel this is feasible.
> > [...]
> >
> > I'm mildly concerned that this adds a strong incentive to start
> > gaming responses to/participation in the user survey going forward,
> > once it gets around that you just need N people to take the survey
> > and claim to be using this project in production so that it can get
> > the coveted "production-ready" tag. I'm probably a little paranoid
> > and certainly would prefer to assume good faith on the part of
> > everyone in our community, but as the community continues to grow
> > that faith gets spread thinner and thinner.
>
> Allow me to re-propose the idea that we are dealing with two separate
> entities here, and need two separate entities to make these calls.
>
> There is the the development side of things, where people work hard to
> get their ideas for OpenStack incorporated into the codebase. There is
> also the distribution side, where people work hard to get a single
> deployable package that others can take and make clouds with.
>
> So what is "production-ready"? And how would you trust any such
> designation? I think that it should be the responsibility of groups
> outside of OpenStack development to make that call. What would that look
> like? Well, let me give you an example.
>
> I have Company A that wants to be known as the simplest OpenStack
> distribution. I invest time and money in packaging the co-gated core
> along with a few helpful other projects, and make that available to my
> customers. There is also Company B, who wants to create the most
> powerful, flexible packaging of OpenStack, and takes the time to not
> only include the basics, but develops tools to handle the more complex
> situations, such as cells or HA designs. This package is not for the
> faint of heart, and for most businesses it would require contracting for
> the services of Company B in order to get their installation up and
> running, as well as fine-tuning it and upgrading it. There are also
> Company C and Company D who target other end-user needs. They all draw
> from the codebase that the OpenStack developers create, and, of course,
> give their feedback as to what changes are needed to make their
> particular customers happy. If they're smart, they'll supply developer
> cycles to help make them happen.
>
> The longer we try to be both sides of this process, the longer we will
> continue to have these back-and-forths about stability vs. innovation.
>
>
> - -- Ed Leafe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iQIcBAEBAgAGBQJVAMjCAAoJEKMgtcocwZqLkKIP/0ReARgypM+eXnu7xDguJIF/
> 6QW8RI7tdHpBFrRZfrBaRahDstFdPQiaBxj1XhFbzoKP+BrUvvfLMnxhJ5cRX0ey
> mz842khScuGmLFzteKvLWwyOia425CZQRnNNaHYjiwii3Agu3a5JTnUi0FeDxZi4
> bD/ZFb/1OxqyVVf2eOJ/T0akVQBqB9QGGNtBnPJEmgEjUl6AhOplLnOkOl1ozRSW
> svlCE7Wyq/Gtl86Ksbj1rfDdArO9Hlh3lwJxaJikfV3O316kqfjx+v7JVcrwdXrK
> qqNtDUpC/tjlReDuDmrPixa0e8/z9Go4TiF1F6nQ4LbY8itMzRKeVbrUPrx4ojlh
> DOE/uOhxh8iTYKOncPsxQlfhbIk0VwzCDWZzDbRxEUpV8Jnzz1ImeosCO3D5/sRL
> G+Rd2gr9rsbwQxtJLA1Q2zQUqnJ6Vvsvx2BgV87ukl0kudF9X/1NaGrJRmeiKYxk
> UDgd0ESYnp9GQMCORcoDa6hNKnPA0yLebqOEyi5dGMwem8JHjYFDx6D9fVfkrxlQ
> 7Kt+SfRmm+1zsHcbZIUz6KEPAvU0cmFdbuG7DwnmKSxpPamUnn3wmpIZRDpdwGIj
> fY3F2dTeEYoNnTyiitLTCKZYE0KaKpFDOAN+FpDNnQJIqQMn/ksxy9/NHYvsmutD
> 5DE1LjWhip9IdcVVm+bT
> =8L0C
> -----END PGP SIGNATURE-----
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>


More information about the Product-wg mailing list