Thanks, Sebastien!
On Thu, Dec 27, 2012 at 6:23 AM, sebgoa <run...@gmail.com> wrote: > in-line > 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: > https://issues.apache.org/jira/login.jsp > and check out existing issues: > https://issues.apache.org/jira/browse/CLOUDSTACK > > You might also get an account on review board (if you have not done so): > https://reviews.apache.org/dashboard/ > > This is the way to submit patches before becoming committer, checkout: > http://incubator.apache.org/cloudstack/develop/non-contributors.html > > Welcome to CloudStack, > > -Sebastien > > > > > Thanks!! > > > > > > On Tue, Dec 18, 2012 at 11:43 AM, Alex Huang <alex.hu...@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 > 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: mike.tutkow...@solidfire.com > > o: 303.746.7302 > > Advancing the way the world uses the > > cloud<http://solidfire.com/solution/overview/?video=play> > > *™* > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
