Open Stack

I find it really hard to comprehend the level of transparency here, or lack thereof. It seems to me that when we want to get features into a given release we are at the mercy of others and while I do understand that the core team cant approve and review everything we also can not wait for another release or another release for features that would be of importance for Openstack in general. Its very discouraging for other members of the community to have certain features which are important for them but maybe not for others being demoted and pushed further out.

Also, having a core set of people vote on what is essential for one release to the next to me is not very transparent and not very democratic way of working, it supports only those who want to guide the community one way. 
While I do see a need for ensuring priority, setting of priority to me is again not transparent imho. Also, having folks comment really late on BP's that have been progressing and folks working hard to progress them only for at the "last minute to get it demoted and then moved to another track" I find this not a nice way to work in the community, politics are a way of life but if they are going to be used as the rule for Openstack and its releases and a way for others to govern within the community I find this really disappointing.

If we have more work being put on the table, then more Core members would definitely go a long way with assisting this, we cant wait for folks to be reviewing stuff as an excuse to not get features landed in a given release.

I know this will strike a cord with some, but I see too much going on that makes me very disappointed so I hope by reaching out others will take note to help us improve this process, perhaps this is something the Openstack Board can take note of and jump in and try and resolve.

Alan

-----Original Message-----
From: Kyle Mestery [mailto:mestery at mestery.com] 
Sent: July-23-14 9:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Specs approved for Juno-3 and exceptions

On Wed, Jul 23, 2014 at 7:28 AM, Salvatore Orlando <sorlando at nicira.com> wrote:
> I'm sure it is not news to anyone that we already have approved a too 
> many specifications for Juno-3. The PTL made clear indeed that "Low priority"
> blueprints are considered best effort.
>
> However, this already leaves us with 23 medium to high specifications 
> to merge in Juno-3. This is already quite close to what the core team 
> can handle, considering history from previous releases and the fact 
> that there are 3 very big items in the list (new LB APIs, distributed 
> router, and group policies).
>
> I've counted already at least 7 requests for spec freeze exceptions on 
> the mailing list, and it is likely more will come. In order to limit 
> oversubscribing, I would suggest to exclude freeze exceptions requests 
> for items which are not:
> - targeting stability and scalability for Neutron FOSS framework
> - have a "community" interest. By that I do not mean necessarily 
> targeting the FOSS bits, but necessarily have support and interest 
> from a number of teams of neutron contributors.
>
> I don't want to be evil to contributors, but I think it is better to 
> be clear now rather than arriving at the end of Juno-3 and having to 
> tell contributors that unfortunately we were not able to give their 
> patches enough review cycles.
>
Thanks for sending this out Salvatore. We are way oversubscribed, and at this point, I'm in agreement on not letting any new exceptions which do not fall under the above guidelines. Given how much is already packed in there, this makes the most sense.

Thanks,
Kyle

> Salvatore
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev