I’ve been thinking about this for a while now, sparked by Ronald Bradford‘s brainstorming about a global hackathon, and I think it’s something that is completely doable, and would have great benefit for MySQL and also the external contributor community. The idea is similar to the PEAR Bug Triage event that occurred a few weeks ago. Basically, the idea is to set aside a time period (1 day, 2 days?) in which the global external contributor community and the MySQL developers come together in a virtual setting and tackle a list of fixable, but low priority, outstanding bugs in the MySQL server and client.
So, what needs to happen for this to become a reality? These are the things I see as current barriers to the event, and issues I hope can be addressed in short order so that a MySQL Bug Triage event can happen sometime in late Western hemisphere (see, Stewart and Lachlan, I don’t forget you guys!) summer or early fall.
Yes, the age-old issue with our current source-control system. While it is true that contributors can use the free bk client, one of the issues folks have is the lack of the free client’s ability to produce a patch/changeset that can be merged into a real tree. So, BitKeeper is currently a barrier to external contributors that would participate in a triage event.
- The current MySQL Contributor License Agreement (CLA)
I agree with Baron, the CLA is a barrier. Why don’t they use the
Apache CLA? Who is able to determine the differences between the MySQL
and Apache CLAs? And who is willing to pay for a lawyer to do so? One
CLA has an active developer community, one does not.
My suggestion is to have two agreements, one which would make it possible for Sun/MySQL to be granted or purchase rights for the contribution to be included in the commercial distributions of MySQL, and another CLA option which would make it possible to grant the contribution only under a shared-copyright, OSS-license-only agreement.
Paul McCullagh takes my suggestion one step further by saying:
So my idea is to collect the rights to contributions under a type of
“MySQL foundation”. Community contributors would then sign a CLA
which is issued by the foundation.
If MySQL/Sun wants pages from the foundation tree, then it buys the
commercial rights to those patches. The foundation then distributes
the income amongst the contributors.
I think either option is a viable one, but resolving the current legal/licensing roadblock with the existing CLA is essential to getting a MySQL bug triage event going. Either we fix it, or important and knowledgeable contributors like Mark, Peter, Baron, Vadim and Paul cannot contribute.
OK, so assuming we resolve the above issues, here is what I think needs to happen in order for the MySQL Bug Triage event to be successful.
Determining a List of Fixable Bugs
Georg Richter and his team have already done a decent job of identifying bugs and worklog items that are deemed easy to fix and not sufficient-enough priority for the MySQL engineering department to be working on. If you look at this list of bugs and worklog items, there is a significant chunk that I think the community can knock out in a couple days, given adequate preparation and working knowledge from the MySQL development organization. So, what preparation and working knowledge is needed?
Although there is a bunch of material on the MySQL Forge wiki on contributing to MySQL, the information is a) not very widely known, and b) not particularly geared towards C/C++ developers looking to fix bugs and/or contribute a feature.
Before a MySQL Bug Triage event, the external contributor who have experience working with the MySQL source code need to do the following, so that other interested community members can quickly get a development environment up and running:
Write detailed instructions for setting up a development environment
If an interested community member is to have a fighting chance at being able to fix bugs in the MySQL server, then she must be able to accurately and easily set up a working debug/development environment on her local machine. Therefore, we need experience MySQL developers and contributors to use the Forge wiki to create detailed instructions for establishing development environments on MacOSX, Windows, and Linux platforms. Who can volunteer to work on these pages? Following the links below to each platform will take you to the stub pages I set up on the Forge wiki for folks to assist in filling in.
There are a number of decent instructions on the Forge wiki already which cover topics regarding building MySQL on various platforms. Perhaps the best is Iggy Galarza’s wiki page on Building MySQL on Windows
What is needed for the Bug Triage event to be successful is all such information about building and debugging MySQL on various platforms needs to be consolidated, structured, reviewed, tested and organized, so that a contributor can quickly get up to speed. Who will answer the call?
- Help with Contributor Development Environment: Linux
- Help with Contributor Development Environment: Windows
- Help with Contributor Development Environment: MacOSX
Organize and Improve the Instructions for Producing Test Cases
The forge wiki currently has a section on How to Write Test Cases, but unfortunately, this wiki page is of a MySQL University session and is not widely known and doesn’t contain very detailed information that steps a contributor through everything they need to know in order to create a test case that covers the bug they are working on. A while a ago, I wrote a blog entry about this very topic, but I need help from contributors and the MySQL development team to verify that all the information in that article is currently accurate and porting the article into the Forge wiki. Who can assist me in this regard?
Can a Bug Triage Event Be Successful?
The above are just my thoughts on making a bug triage event successful. What are your thoughts about this?