<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 8, 2014 at 1:31 AM, Nikola Đipanov <span dir="ltr"><<a href="mailto:ndipanov@redhat.com" target="_blank">ndipanov@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 08/08/2014 12:12 AM, Stefano Maffulli wrote:<br>
> On 08/07/2014 01:41 PM, Eoghan Glynn wrote:<br>
>> My point was simply that we don't have direct control over the<br>
>> contributors' activities<br>
><br>
> This is not correct and I've seen it repeated too often to let it go<br>
> uncorrected: we (the OpenStack project as a whole) have a lot of control<br>
> over contributors to OpenStack. There is a Technical Committee and a<br>
> Board of Directors, corporate members and sponsors... all of these can<br>
> do a lot to make things happen. For example, the Platinum members of the<br>
> Foundation are required at the moment to have at least 'two full time<br>
> equivalents' and I don't see why the board couldn't change that<br>
> requirement, make it more specific.<br>
><br>
<br>
</div>Even if this were true (I don't know if it is or not), I have a hard<br>
time imagining that any such attempt would be effective enough to solve<br>
the current problems.<br>
<br>
I think that OSS software wins in places it does mostly because it *does<br>
not* get managed like a corporate software project. Trying to fit any<br>
classical PM methodology on top of a (very active mind you) OSS project<br>
will likely fail IMHO, due to not only lack of control over contributors<br>
time, but widely different incentives of participating parties.<br></blockquote><div class="gmail_default" style="font-family:'courier new',monospace">+1 </div><div class="gmail_default" style="font-family:'courier new',monospace">
<br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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).</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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).</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
N.<br>
<br>
> OpenStack is not an amateurish project done by volunteers in their free<br>
> time. We have lots of leverage we can apply to get things done.<br>
><br>
> /stef<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>