> -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Wednesday, August 15, 2012 3:13 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [PROPOSAL] Breaking CloudStack into subprojects > > On Wed, Aug 15, 2012 at 5:42 PM, Alex Huang <alex.hu...@citrix.com> > wrote: > > After doing the merge over process one time, I realize something is wrong > with CS structure. We should think about fixing this. > > > > The problems I found are > > > > - I know nothing about the UI but I'm responsible for it. > > - Someone who is a committer can actually check into areas they know > absolutely nothing about. > > - As a release manager, I have no way of knowing whether someone doing > a checkin is actually an expert in that part of the code because of the above. > > > > So this reminded me of a conversation I had with Amr Awadallah, > Cloudera's CTO, when CS joined Apache incubation. I was picking his brains > about how CS should work in Apache given his experience with Hadoop. His > suggested that we break CS into multiple subprojects. We admit committers > to the subprojects based on their experience with that subproject. > > > > I like to see what's the community's response to a structure like that. > Through Murali's work, CloudStack has already been broken down into finer > set of plugins. We can start with every jar is a sub project with committers > assigned to them. It will take a little time to sort out but it will make > going > forward a lot easier. > > > > Please comment. > > > > --Alex > > > My initial gut reaction is 'please no, not that' > The idea of a modular, loosely coupled tools is nice, it plays well with my > sensibilities, and giving that you are proposing it, and Sheng seconds it I > have > no doubt there is technical merit. > > That said I think it ignores some key issues: > One of CloudStack's strengths is that it is a cohesive whole 'product' > that works together. Splitting this out too much has me fearing the result. > We aren't like unix utilities such as grep and bash that can coexist, there > are > plenty of interdependencies. > > As a project we trust our committers. The path to gaining commit privileges is > already one that requires establishing trust and credibility, having multiple > hoops of equal height within the same project baffles my mind. Yes anyone > of those committers could commit changes that are deletirious. But in > general we expect them not to meddle where they have no understanding. > (For instance, you are incredibly unlikely to see me munging with some of > the core internals of CloudStack - I know better and don't need to go tweak > things, or at least if I do to do them in a feature branch) Plus, we have a > revision control system, and commit messages, and commit then review is a > pretty nice way to keep folks who care informed. > > I listen to the hadoop folks talk about the difficulty of setting up Hadoop MR > + HDFS + Hive + Zookeeper + Pig, etc, etc, and the problems they have with > version matching these different projects. Splitting CloudStack into n- > number of subprojects means n-number of releases, and likely independent > releases. > > Not to mention the additional overhead of splitting up into n-number of > subprojects. And honestly this sounds like more of administrative concern > than anything. I personally don't think the community is at the size yet where > we can safely risk fragmentation. >
I don't think different subprojects necessarily mean different releases for each project. It's more of means to put the experts with their expertise. For example, before Hugo became a committer, Jessica Wang, a UI writer, was committer for the Nicira code. For now, I can still tell who's good with what and I happen to the release manager for 4.0. It will be much more difficult for someone else to drive a release. Also I'm not proposing to do it in 4.0. Perhaps the next major release. 4.0 needs to move forward as it is now. --Alex
