What the heck, I'll open a new issue specifically for this, rather than derailing other threads :)

Context: https://drupal.org/node/2002304#comment-7528645

Started working on this awhile ago, if anyone is interested:
https://github.com/drupal-fracture/split-scripts
https://github.com/drupal-fracture

Comments

cweagans’s picture

Preeeeetty sure this isn't going to happen. I floated this idea by webchick a couple years ago, with the addition of letting core module maintainers *actually maintain their modules*. She said something to the effect of "core release management is hard enough. why would we break it up into n different queues, make issues even harder to find, and make the release process more painful than it needs to be?"

I tend to agree with her on this. It's just not worth the trouble.

patcon’s picture

"why would we break it up into n different queues, make issues even harder to find..."

Totally. I guess this hinges on my wider evil plan of proof-of-concepting the use of connector module to hook up Drupal.org accounts to github user accounts to drive repo infrastructure. The @-mention and notification system over there are critical to a split making sense.
#1746386: Github support

I respectfully disagree with the "not worth the trouble" part, but totally understand why you'd feel that way.

cweagans’s picture

IMO, we should just move to github and be done with it. At that point, maybe it makes more sense to split core modules into separate projects or whatever, but I'm definitely -1 to doing that while our code still lives on Drupal.org.

patcon’s picture

Duly noted :)

Hearing something like this makes me all the more excited to figure out a github solution. Glad you're amenable to that part

RobLoach’s picture

Subscribe!

Crell’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)
Related issues: +#1826054: [Meta] Expose Drupal Components outside of Drupal

I'm going to close this in favor of #1826054: [Meta] Expose Drupal Components outside of Drupal, which has more support and is far more likely to happen in the short term.

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.