While I'm certainly not new, I'll add this; DB schema charts are always helpfully especially when we modify the schema every release :). Also a class map(interaction chart) would be nice, however I know that's a near impossible task :)
Sent from my iPhone On Dec 24, 2012, at 11:07 AM, Mike Tutkowski <mike.tutkow...@solidfire.com> 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. > > 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> > *™*
