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
