cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: [PROPOSAL] Breaking CloudStack into subprojects
Date Wed, 15 Aug 2012 23:34:37 GMT
On Wed, Aug 15, 2012 at 6:51 PM, Will Chan <> wrote:
>> -----Original Message-----
>> From: Sheng Liang []
>> Sent: Wednesday, August 15, 2012 3:41 PM
>> To:
>> Subject: RE: [PROPOSAL] Breaking CloudStack into subprojects
>> > Let's take the Netscaler AutoScale feature currently being
>> > implemented.  I'm sure they must be at least touching the API, UI, some
>> Resources layer and DAO layer.  If they were committers, do they have to
>> have been invited to all 4 of those subprojects?
>> This is precisely the type of problem exposed by the separation. We need to
>> address these problems head-on and not try to prolong a large monolithic
>> system.
>> Once we have clean separation of projects developers will be naturally
>> inclined to maintain the separation. Autoscaling should ideally be its own
>> project and not require changes to core CloudStack functionalities.
>> Sheng
> What you suggest makes sense but I don't think we are quite there yet.  Alex is proposing
we assign committers to each of the jar files (defined by him as a subproject) that are currently
being created today.  That seems a bit burdensome to me especially when we already have a
maintainer system setup to review changes and commit patches.
> Will

I think we're talking about two different things:  First, the
architectural approach to the software.  Second, the organizational
approach to managing the software.

For the architectural side of things, I'm a fan of Kelvin's comments
on a separate thread.  We should probably shift that discussion over
to respond to Kelvin.

For the organizational issues, I am very much against making multiple
projects.  I'm using the term project *very* specifically here:  ASF
project / sub-project.  We can certainly revisit this at a later time,
but I don't think we have a large enough community of active
participants to truly break up into different sub-projects.  As it
stands right now, I can see myself only agreeing to sub-projects if
there was an explicit agreement that only the "top level project"
(i.e.: CloudStack) was allowed to perform an official release for the
child components.  (reserving the right to evolve my opinion)

I completely understand Alex's concern (all the more so, knowing how
intimate he is with the product as a whole).  This is  complex system,
and I've experienced a similar issue acting in that role for internal
projects in the past.  One person can't be the expert in all layers /
modules.  Adding to this: regardless of how clean we separate the
layers, many features will still have to have code that slices
vertically through the architecture.

The way to deal with this is to think about the role Alex stepped up
for a bit differently.  It shouldn't be his responsibility to
personally *approve* with all changes.  Instead, being the release
branch "gatekeeper" should be a semi-technical and semi-administrative
function.  Clearly using his own knowledge to verify patches is of
significant value to the project, but the administrative function is
to ensure that (1) the commits have been tested, (2) the appropriate
developers have reviewed the commits, (3) communicate with the
community if there is a reason to keep something out of the release
branch so that we can ensure a consensus driven approach to decisions.

For identifying the appropriate reviewers of any commit (point 2
above), we have already established a "maintainer" list [1] that I
think we have already agreed to. Alex should be leaning heavily on the
people mentioned in that list!



View raw message