> The first thing that comes to mind when I read this was the other open > source cloud automation platform, and not in a good way. > > We need (IMHO) to ship CloudStack as an atomic unit without worrying > about which versions of which components work together. By breaking the > components out, QA workload and release management workload both > increase - significantly, I suspect.
Let me clarify. I'm not suggesting we ship them separately. It should be still a single release and under single PMC. It's a strong point for CloudStack and we shouldn't move away from that. But we might be able to divide up the mailing list to relevant parts or as Marcus says in another reply, have specific members for different parts so people know who to go to . > > >> 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. > > Valid issues...I think the answer, whether we break apart or not, is for > individuals to dig into the areas they're interested in, and as they learn, to > the contribute back on reviewBoard/etc. Maybe if we had intro wiki pages > for the major components of ACS? > > > >> 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. > > I think we're making progress in this area over the last month - as more > [DISCUSS] threads appear, there's more examples for folks to learn from. I also want to add one part about this. I'm not suggesting we introduce processes as rules and regulations. It is meant to be guidelines. > > >> 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. > > > 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. > > This one goes beyond code, but even to posting ideas/thoughts on mailing > lists. Always plenty of lurkers. Folks - we don't bite, promise. > Good idea! Please don't be shy with what we can do to make it easier for you to contribute! --Alex
