incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [PROPOSAL] Breaking CloudStack into subprojects
Date Wed, 15 Aug 2012 22:33:42 GMT


> -----Original Message-----
> From: David Nalley [mailto:david@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.Huang@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

Mime
View raw message