Open Stack

+1 to what john said,

I would also like to wait and see on this... I'd rather be honest with ourselves, and to contributors new and old, and admit core reviewers are air traffic controllers (directing the project vs reviewing changes, two very different things IMHO) and reflecting that in what we say, what we do and how the community operates... (the long term effects of such a change may be hard to predict IMHO).

But I'll hold more of my opinion until I see more details on this...

Sent from my really tiny device...

On Aug 9, 2014, at 11:41 AM, "John Griffith" <john.griffith at solidfire.com<mailto:john.griffith at solidfire.com>> wrote:




On Fri, Aug 8, 2014 at 1:31 AM, Nikola Đipanov <ndipanov at redhat.com<mailto:ndipanov at redhat.com>> wrote:
On 08/08/2014 12:12 AM, Stefano Maffulli wrote:
> On 08/07/2014 01:41 PM, Eoghan Glynn wrote:
>> My point was simply that we don't have direct control over the
>> contributors' activities
>
> This is not correct and I've seen it repeated too often to let it go
> uncorrected: we (the OpenStack project as a whole) have a lot of control
> over contributors to OpenStack. There is a Technical Committee and a
> Board of Directors, corporate members and sponsors... all of these can
> do a lot to make things happen. For example, the Platinum members of the
> Foundation are required at the moment to have at least 'two full time
> equivalents' and I don't see why the board couldn't change that
> requirement, make it more specific.
>

Even if this were true (I don't know if it is or not), I have a hard
time imagining that any such attempt would be effective enough to solve
the current problems.

I think that OSS software wins in places it does mostly because it *does
not* get managed like a corporate software project. Trying to fit any
classical PM methodology on top of a (very active mind you) OSS project
will likely fail IMHO, due to not only lack of control over contributors
time, but widely different incentives of participating parties.
​+1

I see this as a step in the wrong direction for sure.  I also don't know about the "slots" approach that's being discussed.  Seems a better way to address some of this is "content criteria" sort of like what's been discussed on and off in this thread.  So an LTS model of sorts, like saying "these are the types of changes for this release".​  Maybe that's buried in some of that proposals here.... not sure.

We're starting to do some content based rules in Cinder based with respect to milestones, for example we tried to say "hey, if you want to add a new 3'rd party driver for Cinder, you need to do it by the second milestone so the remainder of the release can be focused on the core.  This didn't work out as well as we'd hoped but I think we can get better (and there's been some suggestion of moving it further up like first milestone).  We've also tried things like "cleanup submissions", so things like additions of hacking rules etc have specific windows.  One of the reasons for this is just simply to keep from unintentionally forcing everything behind these changes in the queue to fail and need a rebase.

I don't know that what we've tried so far is really the right approach, but it was a descent learning experience and I think we can take something away from it and try a new approach with what we've learned (this will be a topic for Paris for sure).

Anyway, the slots and runway approach is a bit off putting for me; but I don't want to form any opinions until I read more about what Michael has to say based on the Nova meeting.  Also want to make sure I fully understand the concepts (which I might not currently).

The only thing I would say is that moving further and further to models that limit slots or whatever might have an unintended consequence of pushing away new contributors that maybe aren't being driven by their employer or tactical motivations.  Kinda be a bummer to put up walls like that I think.  It's pretty hard to submit changes already, we've got a lot of process and spend a lot of time on consensus building, I'd hate to make those things to take up even more of our time.  Process is good IMO but it should be implemented to save time, not require more of it.


N.

> OpenStack is not an amateurish project done by volunteers in their free
> time.  We have lots of leverage we can apply to get things done.
>
> /stef
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto: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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140809/a7b22873/attachment.html>