cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebgoa <>
Subject Re: [DISCUSS] What can we do to help CloudStack community be more involved
Date Thu, 27 Dec 2012 13:23:19 GMT
On Dec 24, 2012, at 8:07 PM, Mike Tutkowski wrote:

> "So here's how I'd like to address this - for the new folks (or those
> thinking of contributing) - tell us, how can we make it easier for you to
> dip your toes into the water? Better dev docs? Better QA instructions? More
> examples on how to modify the code? Docs on things like DB schemas,
> functional diagrams, data flow diagrams, what?  Please make suggestions on
> how we can help you."
> I am new to CloudStack and would certainly like to start contributing as
> soon as possible.
> I have noticed it is an extremely large project.  I've been trying to first
> understand it from a user's point of view before I dive deeply into the
> code.
> One thing I am a bit confused about is which branch (of the many branches
> out there) to focus on.  I think I should be looking at the javelin branch,
> but that is not entirely clear to me.
> In my particular case, I work for a block-storage company (SolidFire).
> Although I plan to do extensive development for CloudStack in general, I
> first would like to start understanding the storage component of CloudStack
> and how to integrate SolidFire into CloudStack.
> Where do people recommend I begin?  I know there is a storage-refactoring
> effort on going.  Should I help out with this effort or is this covered by
> existing developers already?  I just need a little guidance as I begin, but
> I am very eager to learn and participate in CloudStack development.  The
> opportunity to work on CloudStack full time was a huge reason I decided to
> come over to SolidFire from HP, so I am definitely excited to dig in.  It
> seems like a fascinating project.

Dear Mike,

I believe you are correct and the storage refactoring is happening in the javelin branch.
Edison Su is the lead on this. 
Due to the holiday season, folks may be a bit slow to answer your mail though.

If you have not done so you should get a JIRA account:
and check out existing issues:

You might also get an account on review board (if you have not done so):

This is the way to submit patches before becoming committer, checkout:

Welcome to CloudStack,


> Thanks!!
> On Tue, Dec 18, 2012 at 11:43 AM, Alex Huang <> wrote:
>> Hi All,
>> I've talked to various developers on the challenges they face in
>> participating in the community and these are issues that I've gathered.  I
>> hope this adds to the recent discussions about project bylaws and  concerns
>> about community health and collaboration procedure.
>>> The biggest issue I believe is CloudStack is too big a project.  When
>> you look
>>> at CloudStack, it can really be broken down to five or six different
>> parts that
>>> can be projects within its own right.  I don't want this discussion to
>> turn into
>>> what those projects are as that should happen on the -dev list, but,
>> just to
>>> give a reference, cloudstack can be broken into orchestration, VR,
>>> automation, template management, acl, UI, and console proxy.  Each of
>>> these parts can require special set of knowledge.  And to some it can be
>>> broken into even finer parts.
>>> This leads to the following problems that I often hear when I talk to
>> other
>>> developers.
>>> - The mailing list is too verbose and is often not about the subject
>> they can
>>> respond to.  The problem is they get into a habit of not looking at the
>> mailing
>>> list because it's often not about what they can respond to but then
>> misses
>>> things that they can respond to.
>>> - The same problem with the review boards.  Most of them don't feel they
>>> understand CloudStack sufficiently to be trolling the review board.
>>> - Many of them feel insecure about posting designs because the project is
>>> overwhelming.  Many of them want to get their designs just right before
>>> posting to the list.
>>> The second issue is we have not developed a good set of processes for
>>> people to follow.  What does it mean to post a design?  What does it
>> mean to
>>> fix a bug?  How does one participate in a release? Etc.  Every bit of
>> ambiguity
>>> leads to insecurity which leads to inactivity.
>>> The third issue is lack of confidence in the code they write.  For
>> example,
>>> today anything someone writes must be tested with the entire cloudstack
>>> system which means they must know quite a bit of the system to get
>> started.
>>> They can't just say I wrote a plugin and which test driver I should test
>> it with
>>> to know it will work inside CloudStack.  This is different from unit
>> tests.
>>> These are tests that CloudStack community provides to test contracts
>>> between projects but because there's no separate projects today, there's
>> no
>>> such tests being developed.
>>> Please comment.
>>> --Alex
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e:
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<>
> *™*

View raw message