Drizzle contributors: It's time to get our act together :)
Sure, we all know that Drizzle is in its infancy. But, that doesn't mean we can't come together and start to act as a team, instead of the current everyone-go-in-a-different-direction "strategy" that has been happening up until now. Don't get me wrong -- experimentation and freedom to innovate is what Drizzle is all about -- but there comes a point where developers need to put down their coding fingers and put on their testing gloves. What is the point of a build farm if nobody fixes the failures it points out? What is the point of a blueprints/roadmap system if nobody updates tasks or even creates tasks in order to track their progress? In short, what is the point of a community if not to come together as a team and make something that is greater than the sum of its parts? And therefore, I am proposing a few procedures that can help us coalesce as a team (SQL-pun intended). Given the absence of negative feedback from the list, I will begin to enforce these guidelines so that Drizzle can continue to move forward, but with a more structured method to the madness. == #1: No direct code commits to TRUNK == TRUNK -- the active development branch (lp:drizzle) -- should not be directly committed to. Instead, code is committed to a local branch and then pushed to a branch on launchpad.net/~username/drizzle/. TRUNK only changes when another branch is merged into it. Merge captains will be responsible for testing that the branch's code passes tests in the build farm and will be responsible for resolving any merge conflicts that may occur, and then merging the branch into TRUNK. This should reduce instability in TRUNK and allow merge captains to better control what is going into TRUNK. Merge captains can be anyone familiar with the process of pulling a branch, merging locally, and working with the build farm to ensure a proper build and test on at least the most popular platforms. The merge captain should be available on IRC to answer any questions and should change the IRC topic to indicate they are the merge captain for the [week|2 weeks|month]. Basically, the merge captain is the gatekeeper into TRUNK. This IS NOT a glorious or highly-coveted position -- mainly it is boring, tedious, grunt work -- so be kind to those who are the merge captains! I will set up a schedule on the Drizzle wiki so that contributors can easily tell who is the merge captain for a particular week. I'll be posting instructions for merge captains to do their work on the Drizzle wiki so anyone interested in helping out can quickly get up to speed. In the meantime, this article on my blog should get you familiar with the process of code management with Launchpad and Bazaar: http://www.jpipes.com/index.php?/archives/250-A-Contributors-Guide-to-Launchpad.net-Part-2-Code-Management.html == #2: Bugs take precedence over new code == The mark of good software, at least in this developer's opinion, is the willingness and ability of the developers to address and fix bugs in the software. We ALL know it's more fun to code up a new feature than to diagnose and fix a bug. That said, it is absolutely imperative to a project's reputation that bugs are looked at in a timely and effective manner. Currently, our build farm -- one of the earliest successes of the Drizzle project -- sits in almost constant failed state. Why? Likely, because of a small build or test bug that nobody is looking at. Community, let's get that build farm TOTALLY GREEN. I want people coming to the Drizzle project to see our build farm grid and say "Dang, I guess these developers are really paying attention to bugs! Looks pretty stable...", and not "Wow, nothing seems to be working..." == #3: Let's use the resources of our community == Hey, not everyone is a C++ guru. There are PLENTY of things that need to be done that have nothing to do with C++ coding. Documentation needs to be written. Developers need help managing tasks and milestones. The build farm needs to be maintained and enhanced. Test cases need to be written. Presentations about Drizzle need to be submitted and given at conferences and camps. Merge captains need to be found and merge work done. Work on the various connectors needs to be planned and started. In short, there is a ton of work to be done by everyone. I get the feeling that various folks *want* to help, but don't really know where to start. If you are one of these community members, looking for ways to contribute, then let's give you something to work on. Part of the problem is not having a driving direction at the moment. This will be changing shortly, as the Cirrus milestone starts to get formalized. Myself, and other contributors, will start to post tasks to the mailing list for contributors to pick up if they are interested in them. These tasks will not be C++ coding, but rather other vital tasks that need to be done. == #4: Teamwork == We are all part of the Drizzle community. So let's start acting that way. I think one of the best ways to help get the teamwork spirit kindled is to start with a specific team, have like-minded contributors join the team, and then have that team document their processes and help another team get going. In response to #2 above, I'd like to suggest the first team be Drizzle Bug-Killers. I've created a wiki page: http://drizzle.wikia.com/wiki/Team:BugKillers for this team, and I encourage any community member who is interested in finding, fixing, and otherwise eradicating bugs from Drizzle to join the team by putting their IRC nick and/or Launchpad homepage link on this wiki page. I will leave it up to the team members to define what immediate goals they have in regards to killing bugs... == #5: Using the Blueprints system == The Blueprints system is a wonderful tool on Launchpad.net that is available for us to use, and so we should take advantage of it. Tasks are easy enough to set up and to assign to a branch and a developer. I'll be publishing an article on my blog tomorrow which explains the Blueprints system in depth and hopefully we can a) cleanup what currently exists on the blueprints list, and b) add small, specific tasks which correspond to targeted functionality for the Cirrus milestone. More to come about this in a later email. OK, so that's it for now. What does the community think about the above guidelines? Do they work for you? Can you envision making a difference in the Drizzle community as a contributor? Anything you don't like? Let me know. Cheers, Jay _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
