Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <B1DF26ECC0458748AC97CECE2DA98D41012F9EB38A0D@SJCPMAILBOX01.citrite.net>
References: 
 <B1DF26ECC0458748AC97CECE2DA98D41012F9EB389EB@SJCPMAILBOX01.citrite.net>
 <CAKprHVYy5HZtfygYoM2ga4mZO_SrOYnMSSJx05N1CZbiXwyrXg@mail.gmail.com>
 <B1DF26ECC0458748AC97CECE2DA98D41012F9EB38A0D@SJCPMAILBOX01.citrite.net>
From: David Nalley <david@gnsa.us>
Date: Wed, 15 Aug 2012 18:45:09 -0400
Message-ID: 
 <CAKprHVZ+FHqHwfuufKWDFTE3jpvLoPOA+i9vGR4s8Vk6YTVz3g@mail.gmail.com>
Subject: Re: [PROPOSAL] Breaking CloudStack into subprojects
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 15, 2012 at 6:33 PM, Alex Huang <Alex.Huang@citrix.com> wrote:
>
>
>> -----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 wr=
ong
>> 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 bra=
ins
>> about how CS should work in Apache given his experience with Hadoop.  Hi=
s
>> suggested that we break CS into multiple subprojects.  We admit committe=
rs
>> 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 fine=
r
>> set of plugins.  We can start with every jar is a sub project with commi=
tters
>> assigned to them.  It will take a little time to sort out but it will ma=
ke 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 i=
t 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 resu=
lt.
>> We aren't like unix utilities such as grep and bash that can coexist, th=
ere are
>> plenty of interdependencies.
>>
>> As a project we trust our committers. The path to gaining commit privile=
ges is
>> already one that requires establishing trust and credibility, having mul=
tiple
>> hoops of equal height within the same project baffles my mind. Yes anyon=
e
>> 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 o=
f
>> the core internals of CloudStack - I know better and don't need to go tw=
eak
>> things, or at least if I do to do them in a feature branch) Plus, we hav=
e 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 Had=
oop MR
>> + HDFS + Hive + Zookeeper + Pig, etc, etc, and the problems they have wi=
th
>> 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 concer=
n
>> 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 f=
or each project.  It's more of means to put the experts with their expertis=
e.  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:
http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-commits/20120=
7.mbox/%3C20120712001514.3D69313264%40tyr.zones.apache.org%3E

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
it.

--David