cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: [PROPOSAL] Breaking CloudStack into subprojects
Date Wed, 15 Aug 2012 22:45:09 GMT
On Wed, Aug 15, 2012 at 6:33 PM, Alex Huang <> wrote:
>> -----Original Message-----
>> From: David Nalley []
>> Sent: Wednesday, August 15, 2012 3:13 PM
>> To:
>> Subject: Re: [PROPOSAL] Breaking CloudStack into subprojects
>> On Wed, Aug 15, 2012 at 5:42 PM, Alex Huang <>
>> 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.

Huh? I see Murali as the committer for that code:

That gets back to people reviewing what they know, I didn't review
Hugo's patch as I know precious little about Nicira's NVP or the
CloudStack end of the code. I don't think we have an abundance (or
any) of that happening. If we do, we still have means of dealing with


View raw message