> -----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. > > --David
I like the idea but it just doesn't seem practical to me right now. Let's take the Netscaler AutoScale feature currently being implemented. I'm sure they must be at least touching the API, UI, some Resources layer and DAO layer. If they were committers, do they have to have been invited to all 4 of those subprojects? On the other hand, when they submit a patch that touches multiple subprojects, do you need multiple committers? I would assume previously, you just had a couple of maintainers review this patch but there was only a single committer. Now, with subproject permissions, that may not be the case? I do agree Alex, that you are unqualified to review UI changes, but presumably, all you are doing is cherry-picking check-ins that have already been reviewed by someone that had that expertise (i.e. Jessica/Brian/Olga)? Is that the problem you are facing right now because I thought the current maintainer model seems to work in general but I could be wrong. Will
