incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: [PROPOSAL] Breaking CloudStack into subprojects
Date Wed, 15 Aug 2012 22:13:06 GMT
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.

--David

Mime
View raw message