BoF Summary: Community Contributions to MYSQL
By Duleepa Wijayawardhana on Apr 22, 2009
A complete and unadulterated dump of what was being talked about, I hope I got the right names and people, comment if anything out of sorts here, the Forge links talked about are here: http://forge.mysql.com/wiki/Contributing
The BoF session was hosted by Lenz Grimmer and Tomas Ulin of MySQL
MySQL Community contributor BoF. About 15 people.
Lenz: Trying to open up, make internal processes trasnsparent, make discussions public, how does code evolve, reviewed etc before release. Lenz shows the "golden rules"
transparency - what's going to happen, how it will be accepted, make it clear to the contributor.
dialog - Lenz admits many patches during the review over the last few months haven't even been acknowledged and are going through the backlog to discover whether any dialog has been done wven if it is to say that we don't
setting expectations: what do we expect. in the past the patch contributor dropped the code and left. We need to be able tohave the contributor to get the patch in shape for acceptance
small is beautiful: better to hone your contribution and skills by working on small piece where there is less code being changed (e.g. small bug fixes).
differences: not all contributors are the same, so recognize the differences and leverage their experience.
places: all contribution have a place to go. It needs to be clear to the contributor, simplify the process, simplify the locations.
Parralellism, Incrementalism; Learning - work must happen in conjunction with others. learning platform so that people have examples for how to do things. Establishing best practices.
It is about us and our developers changing our mindset.
Team has been working since the beginning of the year. Moving away from the old MySQL agreements to the Sun Contributor Agreement. Internal feedback has been good and have been working to make this a success. Looking into existing patches, getting the SCA sign, documenting the process.
Canonical guys: How do you ease the learning curve of getting the code in?
Lenz: it takes a bit of stamina and excitement.
Audience: each code has two reviewers and have the new person as part of the review purposes.
Lenz: in our case devs have been in the community.
Lenz: we have resource struggle to review all our code.
Audience: Is code review an assigned task? On-call reviewers?
How do you track your patches: By email currently which goes into a database. the review process may happen on a mailing lists which might not be visible to all. Part of this process is to making this simpler, automated and transparent.
Lenz: Current updates
Moved from BitKeepr to Bazaar
Forge Wiki links
Simplified SCA - SCA has more rights to the contributor
New development/release cycle
Is there any scope for worklog entries to be editable by community?
We have talked about it... general tooling change?
worklog is a todo list for features for mysql server. community can see it, but it is for internal purposes. Bugs, are public for public to see and follow. Currently community cannot create their own worklog entries.
Kostja: We've been wanting to retool, never resourced so it died.
In the ideal world one tool for bugs and features.
Lars: We need to be closer to the community, why not the wiki infrastructure.
Lenz agreed, we have the infrastructure.
Sergei: bugs is how we are taking care of features, easily trackable.
Launchpad blueprints? Currently does not work for what MySQL needs. Canonical: Maybe at version 3.0
Lots of documentation internally for coding standards etc and are looking to move what is needed outside.
Tomas Ulin now...: Release cycle....
Ongoing work on the forge. With 5.4 will work with a new release cycle. We hope to achieve frequent releases and more community features and include requested features faster (Development_Cycle)
Slide with new release cycle: Milestone release model.
Looking for a laser pointer, found..
Release milestones on a 3-6 month cycle, release a stabilized version of RC quality. We are talking of going from 24 months to 3-6 months. Achieve this with much smaller increments. Previous: Alpha phase has been very long. New: Integration window will be small and will only accept well-tested beta quality patches. Once added, beta release then goes to bug fixing mode and stabilize every 3-6 months. Smaller set of features that we will stabilize over 3-6 months.
How does the numbering work?
Default behaviour, minor version number will be bumped. Slides are just examples, don't get stuck on the numbers.
Kostja: By this new numbering our release model will change so current numbering might be different once we finalize.
A milestone release becomes a potential candidate for becoming a GA candidate. Going over the slide.. Once the release becomes a release branch then not much difference from what we have.
Not every milestone release becomes a GA release branch. Really it is there to maintain disciple so we don't reduce quality and efficiency.
Over time, have max 2 releases in active support and planning GA releases every 12-18 months. 2 releases considering the number of platforms MySQL support.
Kostja: this is an intermediate solution. I would like it to go to a next step where we plan for milestones, Drawback is that a lot of stuff is kept in local trees, you have to consistently merge with the trunk.
We need to have a staging tree, need rigourous testing, need to be strict about not bringing too many features on board. Strict REMOVAL of features instead of delaying releases.
A community contribution will likely be a feature tree which will be tested and be available.
How many staging trees?
Last slide how we see it happening...