openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2012/2/24  <Ed_Conzel@xxxxxxxx>:
> I like most of what you say, but the ""no new features at all" policy
> for trunk for the Folsom" causes concern. I absolutely agree that Nova
> needs to be more stable, predictable and  have more work done around
> operations. This is especially true for service provider usage. I
> think if Nova was closer to feature complete, that the ""no new
> features at all" policy for trunk for the Folsom" would be fine. It is
> probably doable for Folsom if the focus is on private cloud
> functionality. But for service providers, Nova is not feature complete
> and there is still much needed from the operations standpoint.

I understand it's a trade-off. People may feel there are features
missing before they can really use Nova, but noone can use it if it's
unstable or doesn't work. I believe everyone will be better off if we
spend some time (like, say, 6 months time) and focus exclusively on
addressing these things. Thinking we can both add lots of new features
as well as rework things for more stability at the same time is how
we've ended up here.

If you know of a way to achieve both, I'd love to hear about it.

As much as I wish everyone would drop what they are doing and start
helping in this effort, I understand some groups have certain features
they simply cannot defer. I'd like to encourage this to happen
collaboratively in public repos, and with frequent rebases against trunk
to ease inclusion into trunk later on. In a way, they'd be patch sets
more than anything else.

How does that sound to you?

-- 
Soren Hansen             | http://linux2go.dk/
Senior Software Engineer | http://www.cisco.com/
Ubuntu Developer         | http://www.ubuntu.com/
OpenStack Developer      | http://www.openstack.org/