Has the user committee selection/ setup process been discussed before? Does it matter how big a customer the user represents - big co vs individual/ enthusiast?
Thanks, -Sriram -----Original Message----- From: openstack-bounces+sriram=sriramhere....@lists.launchpad.net [mailto:openstack-bounces+sriram=sriramhere....@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: Monday, July 16, 2012 9:08 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom David Kranz wrote: > Going forward, and this may be controversial, I think these kinds of > issues would be best addressed by following these measures: > > 1. Require each blueprint that involves an API change or significant > operational incompatibility to include a significant justification of > why it is necessary, what the impact would be, and a plan for > deprecation/migration. This justification should assume that the remedy > will have to be applied to a large, running OpenStack system in > its many possible variations, without having to shut down the system > for some unknown amount of time. That would be useful. Strengthening a bit the feature proposal process definitely can't hurt. > 2. Require such blueprints to be approved by a technical committee > that includes a significant representation of users/operators. The > tradeoffs can be difficult and need to be discussed. The Foundation bylaws propose that a "User committee" be set up. I hope that the User committee can be quickly set up, gets respected people on it and manages to be representative of all the users/operators of OpenStack. If done properly, such a committee can get very influential and its public "recommendations" cannot be easily ignored by the developer side (the "technical committee"). > 3. The technical committee should declare that the bar for > incompatible changes is high, and getting higher. > > Some might argue that this is too much of a burden and takes authority > away from PTLs, but I think the statement of stability to the > community (and others) would more than compensate for that. Using the "user committee" setup, you don't really need to take authority away from the PTL. You increase the influence of the "users" on technical decisions. You just provide a clear and official mechanism to represent the interests of "the users" as a whole. Once you have that, if the PTL or technical committee decides to ignore it, it's a rather strong decision that better has to be well justified. Its better than having some arbitrary percentage of "users" in a single committee and then have most decisions won by the most largely represented party. If the user committee is an active and respected group, it provides nice checks and balances against developers living in developer bubbles. Most issues we have right now with deployer-friendliness are linked to the fact that "the users" don't have a clear or official voice. The trick is, of course, to manage to set up such a committee in a way that represents all the users and deployers. It will be all the more influential if it is seen as representing all the users, rather than just a loosely-tied pre-determined subset of large users. -- Thierry Carrez (ttx) Release Manager, OpenStack _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
