Open Stack

On Fri, Aug 8, 2014 at 1:31 AM, Nikola Đipanov <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
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140809/ee54e7c4/attachment.html>