Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 mike.tutkowski@solidfire.com does not designate 209.85.219.53 as permitted
 sender)
MIME-Version: 1.0
In-Reply-To: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA334EFFD@SJCPMAILBOX01.citrite.net>
References: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA334EFFD@SJCPMAILBOX01.citrite.net>
Date: Mon, 24 Dec 2012 12:07:48 -0700
Message-ID: 
 <CACOnxCgDS-tORUmjKX6rhYs_oC_gyOFxfExO3YpRvR+ZdCrg7g@mail.gmail.com>
Subject: Re: [DISCUSS] What can we do to help CloudStack community be more
 involved
From: Mike Tutkowski <mike.tutkowski@solidfire.com>
To: cloudstack-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d043bdf28c0877204d19de932

--f46d043bdf28c0877204d19de932
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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

Thanks!!


On Tue, Dec 18, 2012 at 11:43 AM, Alex Huang <Alex.Huang@citrix.com> 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  concer=
ns
> 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 b=
e
> > 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 the=
y
> > 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 tes=
t
> 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
>


--=20
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=3Dplay>
*=99*

--f46d043bdf28c0877204d19de932--