Voting starts in March for the Drupal Association Board election.
In parallel with the discussions surrounding how to integrate a composer based workflow into drupal and its modules, there are infrastructure requirements and impacts that should be considered/discussed/resolved in order to support a composer based workflow for the drupal ecosystem.
Some questions that need to be discussed/clarified in using packagist as our dependency metadata resolution repository.
- What impact will hosting a project the size of drupal have on packagist infrastructure? Can they handle whatever load we're going to send, and is there a cost associated with that?
- What metrics will we be able to collect from packagist?
- What does drupal.org need to do to get first class citizenship like github and bitbucket have for our git repos?
- How are security issues handled with packagist? Will the security team be able to unpublish insecure modules?
- Who owns/manages 'vendor' account at packagist?
- Would this have an impact on updates and the drupal.org's update system? i.e. what happens when a module checks in a composer.lock file with insecure versions?
- How are distributions/install profiles affected by something like this?
- Is packaging/tarballs still needed for d8+ if we go to composer based workflow?
|1||who?||Composer for tarball|
|3||who?||Composer for testing|
|4||who?||Composer for testing|
|7||who?||R&D - can we support distros this way?|
|8||[#] R&D How to support multi-sites?||who?||R&D|
|9||who?||Eventually, subtree split core components|