Managing a Major Open Source Release

Facilitated by Neil Drumm, MAPLight Developer, Drupal developer, api.drupal.org, drupal.org theme.

Neil is the lead maintainer for Drupal 5. In this session he'll share stories and learnings from his experiences, including security process, usability, and the full major-version life cycle, including end-of-lifing major versions.

Drupal organized as a core, and set of modules (over 3000). Only a handful can commit code and it is generally done by the main project lead

Each major realease since 4.7 has had a gatekeep for the code - one person in charge of the release. one main person - project lead

Drupal Germany 5.0 Hungary 6.0 (Big hungarian representation in Drupal) Cananda 7.0 web chick (http://www.webchick.net/) will do the next release

project lead makes the decision. Says 'i want this person to help me out.' all volunteer some people paid for drupal contributions job - reviewing patches 500 conrbituters for drupal 5 (at least one line of code contributed) too many to review all patches, not every release

someone raises issue someone rights patch community checks it out lead reviews

(configurable content types)

Whatever people write - very community driven

at a certain date code freeze (just bug fixes) a few weeks then 'string freeze' (translators can get started roughly set date for release (when release is ready)

Things that don't make it in do allow usablity changes (small things like wording, task flows, how screens work together) to make it more usable. without re-architecthing

WebChick.net post

(is it readable) read comments to see if it firsts look at issue to see if it hits the issue

drupal project module is used for issue tracking

patch review when non critical bugs look manageable do release then in maintenace (bug fixes and security) 3000 modules and x number of themes each of which

internal email list for bugs security@drupal.org

don't announce them irc on Wedneday morning

no Drupal non-profit not in charge of code, just m

community and Dries Buytaert are in charge of the code Servers in Belguim

Giving people space and tools around which to talk to each other A lot moved off of mailing lists and to groups.drupal.org

Give people the space they need to collaborate.

Question: how to get ball rolling on issue if Advice: Won't add a module unless using it on two sites (for example reused code from one MapLight module to submit another module.)

Each module has a home page on drupal.org Be explicit about involvement because people want to know how much involvement they can expect from you.

Look for people working on similar problems, possibly contribute to an existing module.

Advice to people just getting started: Start with basics (mailing list, cvs and issue tracker) then build out new stuff as needed. empty mailing lists are not useful.

In early days CVS was used as issue tracker - this is not recommended.

Basecamp works good for issue manangement, but make sure discussions that should be public that they are fully public.. Documentation is a wiki-like documentation system. Often point people there. Want in code documentation, and to make that accessible.

---

Session take aways: Informal review process on core patches. Modules are community maintained. Give people infrastructure to work on. (Drupal acts as a platform) Provide people spaces to collaborate, but don't overengineer it. If have API want to have good API docs (good documentation and inline documentation)