[PP-1] Establish the repository layout

+1 this is inline with our expectation that starshot will produce components that are usable outside of starshot.

I think this has implications for testing too. Each component should have its own tests.

Sorry -1 from me for a few reasons:

1. There is no intention to provide any kind of installable/downloadable project called 'starshot'. The working name for the eventual product has been 'Drupal CMS', which might or might not stick, but this means there should be no code in this project at all. Maybe it'll get retired into the eventual new project once a name is settled on with issues migrated, maybe it'll stay as a meta-project like the ideas queue, but either way it's not where code should live.

2. If we're avoiding starshot-specific modules and themes (which we definitely should), that leaves the composer template and recipes.

I would think we want the recipes to be browsable by project browser independently of starshot once that's possible, and ideally usable in their own right before then too.

While recipe hosting on Drupal.org is still partially TBD, they can already be hosted as general projects with a promise from the DA that if a specific project type gets added they'll all be migrated over. This would allow starshot/drupal cms to pull them in as composer dependencies before project browser browsing/unpacking is ready, but it would also mean that when project browser can eventually browse recipes from d.o everything will be ready to go.

If we want to do a subtree split, it would need to be a subtree split to individual Drupal.org projects which as far as I know is not currently possible. Maybe that's the ideal scenario but it would need a Drupal infra issue to support that workflow, which would then block the above until it's done.

Having lots of micro-recipes in lots of different projects without a subtree split would also be a pain to maintain though, but I think there's a middle-ground where we have a single 'starshot recipes' project (with a different name to that) hosting all the recipes, which would at least allow those to be composer required independently of the composer template then - even if it's in one go. Then we could subtree-split from that project into the smaller recipes once that's supported.

I've not heard any objections here, and this is easy to change later if we want, so I'm merging it.

There is no intention to provide any kind of installable/downloadable project called 'starshot'. The working name for the eventual product has been 'Drupal CMS', which might or might not stick, but this means there should be no code in this project at all.

I don't understand how that has to relate to the name of the repository? We all know Starshot is a temporary name, but we can migrate any code we commit to another repository later, under a different name, as long as the package names published to Packagist don't change.

If we're avoiding starshot-specific modules and themes (which we definitely should), that leaves the composer template and recipes.

IMHO the pragmatic policy here is "avoid Starshot-specific extensions if at all possible, but use them as a last resort".

I would think we want the recipes to be browsable by project browser independently of starshot once that's possible, and ideally usable in their own right before then too.

Yeah, that's my understanding of the vision too. How does a monorepo architecture prevent any of this, any more than Symfony's monorepo architecture prevents mixing-and-matching of Symfony components in other projects?

While recipe hosting on Drupal.org is still partially TBD, they can already be hosted as general projects with a promise from the DA that if a specific project type gets added they'll all be migrated over.

That's the impression I've gotten from @drumm too, but he also gave me the sense that Starshot packages (including recipes) would be published to Packagist, since packages.d.o is, at the end of the day, a shim. He can probably comment on this point more robustly than I can.

If we want to do a subtree split, it would need to be a subtree split to individual Drupal.org projects

I was thinking we'd subtree split to individual packages on Packagist, not d.o projects.

Having lots of micro-recipes in lots of different projects without a subtree split would also be a pain to maintain though, but I think there's a middle-ground where we have a single 'starshot recipes' project (with a different name to that) hosting all the recipes

This sounds like it contradicts the design of the recipe system. Every recipe needs to be its own individual Composer package; assembling multiple recipes together with no additional recipe instructions, is a metapackage.

I was thinking we'd subtree split to individual packages on Packagist, not d.o projects.

Project browser browses d.o projects out of the box, so it needs d.o projects to browse, not just composer repos published to packagist.

Postponing this on #3452281: Decide on Starshot's product name → since there will need to be a new project(s) to host the actual code instead of this one.

This is done now: https://git.drupalcode.org/project/drupal_cms

Automatically closed - issue fixed for 2 weeks with no activity.