[openstack-dev] The Evolution of core developer to maintainer?

Duncan Thomas duncan.thomas at gmail.com
Wed Apr 1 16:31:54 UTC 2015

On 1 April 2015 at 10:04, Joshua Harlow <harlowja at outlook.com> wrote:

> +1 to this. There will always be people who will want to work on fun stuff
> and those who don't; it's the job of leadership in the community to direct
> people if they can (but also the same job of that leadership to understand
> that they can't direct everyone; it is open-source after all and saying
> 'no' to people just makes them run to some other project that doesn't do
> this...).
> IMHO (and a rant probably better for another thread) but I've seen to many
> projects/specs/split-outs (ie, scheduler tweaks, constraint solving
> scheduler...) get abandoned because of cores saying this or that is the
> priority right now (and this in all honesty pisses me off); I don't feel
> this is right (cores should be leaders and guides, not dictators); if a
> core is going to tell anyone that then they better act as a guide to the
> person they are telling that to and make sure they lead that person they
> just told "no"; after all any child can say "no" but it takes a real
> man/woman to go the extra distance...
So I think saying no is sometimes a vital part of the core team's role,
keeping up code quality and vision is really hard to do while new features
are flooding in, and doing architectural reworking while features are
merging is an epic task. There are also plenty of features that don't
necessarily fit the shared vision of the project; just because we can do
something doesn't mean we should. For example: there are plenty of
companies trying to turn Openstack into a datacentre manager rather than a
cloud (i.e. too much focus on pets .v. cattle style VMs), and I think we're
right to push back against that.

Right now there are some strong indications that there are areas we are
very weak at (nova network still being preferred to neutron, the amount of
difficultly people had establishing 3rd party CI setups for cinder) that
really *should* be prioritised over new features.

That said, some projects can be worked on successfully in parallel with the
main development - I suspect that a scheduler split out proposal is one of
them. This doesn't need much/any buy-in from cores, it can be demonstrated
in a fairly complete state before it is evaluated, so the only buyi-in
needed is on the concept. This is a common development mode in the kernel
world too.

Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150401/6efac671/attachment.html>

More information about the OpenStack-dev mailing list