Voting starts in March for the Drupal Association Board election.
Note, 2012-04-06: The current backport policy is now documented here: Backport policy
The process for backporting fixes from Drupal 7 to Drupal 6 was/is quite broken.
and are the best examples of it not working at all - i.e. we have a bug in Drupal 6 that blocked the Drupal 7 release, but released Drupal 7 anyway because there was /never/ an issue or patch for Drupal 6 in the queue, and it also wasn't being tracked in the Drupal 7 queue either.
Another issue we have is that patches to Drupal 7 often needed followup (minor or major bug fixes, documentation, tests added) for Drupal 7, as well as a backport to Drupal 6, and a single issue can't handle both things at once across two version.
So let's fix that for Drupal 7.
There are at least three things to figure out:
- Once Drupal 8 opens up, do we always patch against Drupal 8 and backport, or will some things go into 7 and forward port?
- For backports, should we start opening parallel Drupal 7 and 8 issues, but mark one or the other postponed?
- There's been indications from Dries that API additions, performance improvements etc. might well be accepted to Drupal 7 if they don't break existing APIs, but I don't know to what extent this has been discussed, or what webchick thinks about it either. I know I personally have several performance patches (mainly around i/o and memory at the moment) split between the Drupal 7 and 8 queues, that once ready would be backport candidates, but I'm not even sure which version to target the patches at at the moment.
There are 224 Major issues against Drupal 7 at the moment, not to mention all the 'normal' ones, so this is something we should figure out a process for sooner rather than later.
Posting this against Drupal 7 since that's where the backports land, and it will likely be webchick doing a lot of the commits.
Marking this as critical since it should be sorted out before we get to a 7.1 and/or before 8.x is branched if at all possible.