Shawn, If each "little group" had at least one active Nova core member, i think it would speed things up way faster IMHO.
-- dims On Wed, Aug 28, 2013 at 9:40 AM, Shawn Hartsock <hartso...@vmware.com>wrote: > tl;dr at the end... I can ramble on a bit. > > I agree with Daniel. > > I'm not a core reviewer, but I'm trying to think like one. Over the last > few weeks I've divested myself of almost all coding tasks, instead trying > to increase the size of the community that is actively contributing to my > area of expertise. I have indeed gone batty! I've caught myself a few > times, and the frustration of feeling like I couldn't contribute code even > if I wanted to is getting to be a bit too much. > > The common refrain I've heard is, "That's OpenSource" as if this is a > natural state of affairs for OpenSource projects. I've been either on or > around OpenSource projects for nearly 20 years at this point and I really > feel this doesn't have to be the case. Any project is doomed to have an > internal structure that mirrors the organization that maintains it. That > means software beyond a certain scale becomes part engineering and part > state-craft. > > In OpenSource projects that I have worked on recently, the way scale was > handled was to break up the project into pieces small enough for teams of 1 > to 5 to handle. The core framework developers worked on exposing API to the > plugin developers. Each plugin developer would then focus on how their > plugin could expose both additional API and leverage framework API. > Feedback went from the application developers to the plugin developers and > up to the core developers. This whole divide-and-conquer strategy was aided > by the fact that we could lean heavily on a custom dependency management > and code/binary distribution system leveraged inside the framework itself. > It meant that package structure and distribution could be controlled by the > community directly to suit its needs. That makes a powerful combination for > building a flexible system but requires a fair amount of infrastructure in > code and hardware. > > It wasn't a perfect solution. This strategy meant that an application or > deployment became the coordination of plugins mixed at run-time. While > efforts were made to test common combinations, it was impossible to test > all combinations. That often meant people in the field were using > combinations that nobody on official teams had ever considered. Because the > plugins weren't on the same release cycle as the core framework (and even > in different code repositories and release infrastructures) a plugin could > release weekly or once every few years depending on its needs and > sub-community. > > There is a separate dysfunction you'll see if you go down this path. Core > API must necessarily lead plugin implementation ... which means you > sometimes get nonsense API with no backing. To solve this a few plugins are > deemed "core" plugins and march in-step with the API release cycle. Then > there's the added burden of longer backward compatibility cycles that > necessarily stretch longer and longer leaving deprecated API lying around > for years as plugin developers are coaxed into leaving them behind (and > subsequent plugin users are coaxed to upgrade). Some things slow down while > others speed up. The core API's evolution slows, the plugin/driver speeds > up. Is that a fair trade off? It's a judgement call. No right answer. > > In the end you trade one kind of problem for another and one kind of > coordination for another. There's no clean answer that just works for this > kind of problem and its why we have so many different kinds of governments > in the world. Because, ultimately, that's what human coordination becomes > if you don't watch out and "one size does not fit all". > > Based on my experiences this last cycle, I think nova is pretty well > broken down already. Each driver is practically its own little group, the > scheduler is surprisingly well fenced off, as are cells. As for our > sub-team I think we could have moved much faster if we had been able to > approve our own driver blueprints some of which have been in review since > May and others which have 30+ revisions updated every few days hoping for > attention. It's part of why I moved to watching over people's work instead > of doing my own and I now spend most of my time giving feedback to reviews > other people are working on and seeking out expert opinions on other > people's efforts. > > It's not a pleasant place to be and every time I pick up something to work > on I either get pulled away or someone else picks up the job and finishes > before I can even get started. I imagine this is much like what it is to be > a core developer and that this contest of interest is the same strain the > core-reviewers feel. You end up picking your own work and neglecting others > or falling on the sword so other people can do their work and doing none of > your own. Frankly, I don't want to use this strategy next cycle because it > is far too unsatisfying for me. > > BTW: > Anyone interested in this on an academic level, most of these ideas I have > are from vague recollections of college readings of the work of W. Edwards > Deming, Coase theorem, and more humorously and directly: Conway's law. But, > I don't do that for a living so I may not understand it too well. Mostly, I > was interested in how to coordinate large numbers of developers. > > tl;dr please don't create a reviewer caste (it's not fun), break the > project into pieces, give the pieces autonomy... for me, that tends to be > more fun. > > # Shawn Hartsock > > ----- Original Message ----- > > From: "Robert Collins" <robe...@robertcollins.net> > > To: "Daniel P. Berrange" <berra...@redhat.com> > > Cc: "OpenStack Development Mailing List" < > openstack-dev@lists.openstack.org> > > Sent: Wednesday, August 28, 2013 6:51:22 AM > > Subject: Re: [openstack-dev] [Nova] Frustrations with review wait times > > > > On 28 August 2013 22:39, Daniel P. Berrange <berra...@redhat.com> wrote: > > > > > No, IIUC, Joshua was suggesting that core team members spend one cycle > > > doing reviews only, with no coding, and then reverse for the next > cycle. > > > That is just far too coarse/crude. Core team members need to be free to > > > balance their time between reviews and coding work on an ongoing basis, > > > just as any other member of the community can. > > > > Oh! Yes, thats way too heavy. > > > > I do wonder about tweaking the balance more [or scaling the review > > team :)], but only-reviews would drive anyone batty. > > > > -Rob > > > > -- > > Robert Collins <rbtcoll...@hp.com> > > Distinguished Technologist > > HP Converged Cloud > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev