Reducing risk in the Drupal 8 release schedule
Post-Drupal 8's feature freeze, we find ourselves in a similar state as we did after Drupal 7's feature freeze:
- Some initiatives are mostly done, and now onto clean-ups.
- Others are mostly architecturally there, but still have some pretty big gaps.
- Still others are either not yet architecturally complete, have a major amount of integration/conversion work left, and/or have many outstanding critical/major bugs.
From here on out, we need to be more strategic about what patches we do and do not allow into Drupal core directly, and this means we have to make some tough decisions. Every patch we commit needs to not move Drupal 8 further from a "shippable state".
There are essentially two categories of initiatives (both official and unofficial) that are incomplete:
- Code already in HEAD, that we do not plan on reverting, and completion of which is critical to releasing Drupal 8. Examples are CMI, Entity NG, Router conversions. Incremental patches committed to these issues help move Drupal towards release.
- Code not currently in HEAD, or libraries that are sitting around effectively unused by the rest of Drupal. Examples are Twig, CSS re-organization, and parts of SCOTCH. Incremental patches committed to these issues move Drupal towards "uncharted territory", and could put the release of Drupal 8 at risk.
Therefore, the core committers plan to employ the following strategy when deciding what we do/don't commit to Drupal 8 going forward:
First, a patch will be evaluated to see if it belongs to a larger "meta" issue. For the vast majority of issues in the Drupal 8 queue, the answer will be no. For example, routine bug fixes and self-contained DX (Developer Experience) improvements can simply be committed once they're ready.
If an issue is part of a larger meta issue, the question will be whether that meta issue is critical to shipping Drupal 8. If so, the "does this move us towards release?" question is satisfied, and these patches will be committed as they're ready. An example of this is individual CMI conversions; we cannot ship Drupal 8 without all parts of it being deployable through the configuration management system. Similarly, we cannot ship with two methods of declaring routes.
If the meta issue is not deemed critical for release, but we can still ship Drupal 8 with part of it done, then we will also commit patches as they're ready. Views conversions are a good example of this. While it would be nice to ship Drupal 8 with all administrative pages converted to Views, we can still ship Drupal 8 with some converted and others not.
If the patch is part of a larger, non-critical meta issue, but getting part of it done is worse than getting none of it done (an incomplete state will hold up release of Drupal 8), then we're in a "danger zone" and need to look at possible options:
- First, we should see if the patch can be re-worked, or parts of it split off, into self-contained issues. Then those issues' patches can just be committed via the normal process.
- If there is no other option than completing the entire meta issue, then core maintainers will work with each individual team to determine a "cut-off date" for their work (which allows sufficient time prior to July 1 for integration), as well as the safest way for their work to continue without holding up the release. Possible strategies could include:
- a larger patch containing the meta issue in its entirety, with no follow-ups, where it is still feasible to use a patch-based workflow (e.g. CSS re-organization).
- a branch off the Drupal core repository that is merged in when deemed acceptable in the case of larger conversion efforts (e.g. Twig)
- a sandbox project where larger refactoring is still necessary (e.g. SCOTCH).