Making Drupal 6 even more awesome - code sprint tips

With Drupalcon San Francisco just a few days away, being another great event including two days of "pure coding" and a ChX coder lounge each day for those who are inclined to join, I figured it would be a good idea to share some tips if you are about to work on Drupal 6 issues. Given the close to 2700 attendees coming, I don't know how many to expect on the code sprint days right before and after the conference, but I guess there will be people with diverse backgrounds as usual.

We have seen people sprinting to improve Drupal documentation, translate Drupal to foreign languages, improve core and contrib components, and I hope some of you will have itches to scratch around Drupal 6.

As the Drupal 6 maintainer, my main input is the "reviewed and tested by the community" (RTBC) issues for Drupal 6. While at least one people thought of each issue here that it is ready to commit to Drupal 6, we've seen before that asking for more opinions could turn out problems of varying sizes. Therefore I'm trying to be conservative shooting the patches right into core. If it could be all automated, then why would I be involved anyway? So feel free to look at RTBC issues and try to verify that they work well. Changes which were lightly or not tested and multiple verifications do not exist of them running fine will not be committed soon. I try to stress this time to time on concrete issues, but we can consider this a general rule. Drupal 6 does not have a systematic testing framework, and even if your patch passed the D7 testing framework it might have issues in D6 (think PHP 4 compatibility, API changes, code style differences, etc). It is however generally easiest to re-test these patches since that does not require elaborate development skills.

If you do not have specific issues to work on and would like to be of help clearing Drupal 6 off of issues some people thought are critical, then the waiting queue of critical issues is the place to go. Yes, Drupal 6 has one too, not just Drupal 7. While issues here are not release blockers for the next Drupal 6 version, these are the most important issues people found in Drupal. There are certainly outdated and non-critical issues in there, since whatever was critical for one developer might not be generally applicable or could turn out to be a configuration issue. It is generally easier to start from the end of the list, since old issues not encountered by others are either not applicable anymore or were not actually critical. Help in cleaning up this issue queue and writing / reviewing patches in there would be greatly appreciated as well.

While the limelight is on Drupal 7 nowadays, Drupal 6 will be around for quite some time, so helping make it better even in small increments is definitely a worthy contribution. Thanks for all your time spent on helping out maintaining Drupal 6 and see you around at Drupalcon San Francisco.


andypost's picture

DRUPAL-6 issue queue is really needs attention!

Christian Schmidt (c960657)'s picture

I agree. While D7 is exciting and all, most of us will likely be using D6 in our day-jobs for a long time so not only bug fixes but also performance improvements and smaller backwards-compatible feature additions are very much welcome.

I must admit that I haven't been paying much attention to the D6 queue, except for issues that I have worked on in D7. Perhaps it would help gather attention if the “Contributor links” block on d.o contained links to the D6 queues also.

Add new comment