cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [PROPOSAL] Breaking CloudStack into subprojects
Date Fri, 17 Aug 2012 10:05:26 GMT
On Thu, Aug 16, 2012 at 12:42 AM, 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.

Quite possible, however how many times does this actually occur in
practice? And when commits do occur by a not so savvy developer in that
unfamiliar region, is the outcome negative? If there is a problem will the
problem be detected and is it possible to easily revert back?

Erecting fences to guard against these potential problems incurs an
additional administrative overhead. Not only must you manage the
permissions you have to evaluate the abilities of the developers based on a
per subproject basis.

Before discussing what's common at Apache, let's talk more about the OS
way. Erecting fences for the sake of greater control is dangerous. It
divides the community to a degree, and it prevents natural migrations from
one region of the source to another through the "scratch an itch"
mechanism. CloudStack is not like an Apache Commons where everything is
absolutely separable today. It maybe one day, but you want people working
in one area to eventually move into other areas of the source. These fences
will detract from these natural flows. Furthermore now you have different
kinds of committers and a need to evaluate who can work on what.

What's important here is the initial committer evaluation. You want a good
open source citizen who knows their limits and is not going to start
picking at everything without knowing anything about the code base. You
need this trust. There are not many committers here at Apache that think
they know everything and have the gaul to muck around in areas they have no
clue about. Sure there can be a small degree of this, but it's small,
isolated and you really need good unit and integration tests to protect
against this. Finally you do want people to gradually start looking into
areas they may not be very knowledgable in so they eventually become savvy.

As for Apache, the majority of projects here at the ASF, regardless of the
size and complexity of the code base usually grant all or nothing access to
their TLP scope of sources in whatever version control system they use. We
trust in our committers and don't take on committers that seem to lack the
balance to know their limits. We may occasionally find ourselves having to
go into areas of code we are not so familiar with but transparency,
collaboration and communication on the mailing lists help ameliorate the
possible negative impacts. Again unit and integration tests a key to give
us the confidence to try things in areas that might be our core
proficiency. This bolsters trust.

Finally version control is helps correct any problems that might arise in
seconds. Diligence is everyone's responsibility.

> - 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.
Yeah but you're talking about having to determine this apriori. You're
going to have to give out expert badges eventually and do this evaluation:
at least the PMC does.

> 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.
The Hadoop ecosystem, is no longer a single TLP project. It naturally grew
out this way and so too might CS. Incubation, IMHO, is the wrong time to be
trying to build these fences.

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

This obviously helps, not only from a code configuration perspective, but
from the ability to detect alterations on the code with commits to do the

> 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.
I agree with Jim Jag, highly recommending against this. It's not going to
pay off and is a dangerous direction. I can understand previous corporate
control mechanisms around release management being tempting, but in open
source these control mechanisms are unnecessary and lethal.

Best Regards,
-- Alex

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message