Voting starts in March for the Drupal Association Board election.
- Patches involving Symfony components are difficult to review and the sheer size of the patches hide essential changes to Drupal core from prying eyes.
- There's no community consensus on whether we ultimately want to rely on and use Symfony components yet, so it's not guaranteed that the change proposal depending on it will succeed for D8.
- Commit the library, and then show us how you want to use it.
- If you fail to use it in an accepted way, we remove it.
- Upcoming patches for the Web services and Layout initiatives require Symfony components to make their envisioned design work.
- Most of that envisioned architectural design was discussed at a sprint in Boston recently. — This means nothing in terms of general community acceptance for the actual proposed changes. But it is a clear indicator for what's needed in terms of external libraries, and how the involved developers are going to implement that vision.
- and potentially other issues are going to propose architectural changes for Drupal core based on those external libraries.
- Each of those patches is 500+ KB in size, since all of the dependencies are missing and need to be contained in each patch, too.
- The actual changes to Drupal core are much smaller.
- By committing the external libraries first, everyone can properly review all changes in each patch in detail.
- We have ~8 months left to remove unused code from Drupal core.
- The mere fact that the external library code exists is not a guarantee that we will use it, nor that it will stay.
- We apparently did the identical thing with jQuery UI. We merely failed to remove it before we released D7.
- We are not going to touch or change the code of the external library within Drupal core.
- No one is going to review the external library code as part of those core patches either way.
If you want to read and learn about that code, you go to the library's repository or API documentation pages instead. Simply looking at your D8 checkout would be even better.
Commit that symfony component code to core. It's not used by the mere commit.
No sandbox involved. No patch involved.
It reduces the patches in those issues to the actual changes to Drupal core.
Thus, patches are reviewable and manageable, by everyone.
We can remove unused code at any time.
- This very issue will come up again for every single new patch that's posted to any issue for the affected initiatives. Let's solve it once for all. For the time being.