Agile for Drupal core: within-major-version API additions as a key element to the Drupal Developer Experience (DX)

We (the Drupal community) cannot expect webchick to look even once at anything that isn't truly needed for D7's release at this point.

But i think we cannot tell exportables and other developer experience issues to go to hell for the next year or three either.

This has been discussed before, and i'm sure Dries has thought about the extreme contrast between agile regular time-based releases and Drupal's cycle, especially now that the testing framework means in-version changes could be required to have fanatical test coverage–– but it's no longer an abstract when fantastic contributors like webchick and sun wasting each other's time when doing, quite correctly by their own lights, the right thing.

i think there can and must be a policy outlet for these conflicts that could be promised for sometime after D7 is out. Hoping for an expansive interpretation of step 6 of Dries' 8 steps for D8, "Backport small changes to stable releases." It would be a bit like riding a bull, but imagine how completely exportable just the Development Seed crew would make Drupal 7 if they could get needed changes into the in-use version of Drupal (maintaining of course the 8 first, then backport, flow).

Webchick is understandably taking no more, so maybe an additional co-maintainer for API expansions / code refactoring during the D7 cycle would be possible?

Some candidate issues, that have caused considerable pain and heartache trying to get in and will cause a lot more if not resolved:

http://drupal.org/node/902644 "Machine names are too hard to implement. Date types and menu names are not validated"

http://drupal.org/node/709892 "Complete entity CRUD"

http://drupal.org/node/903730 "Text formats need a machine name / missing drupal_alter for formats and filters."

I propose these tickets be tagged with "agile" or "dx" and dealt with early within the Drupal 7 post-release lifecycle.