#### What's the relationship between Drupal CMS and the Starshot prototype?
The Starshot prototype was hacked together in two weeks to prove the concept at DrupalCon Portland. Modules were included based on @phenaproxima's personal preferences, not on any kind of process or methodology. There was no expectation that anything in the prototype would necessarily make it into the final Drupal CMS product, and there still isn't.
That said, the prototype did several things quite well: it established a reasonable repository layout, made workable infrastructural decisions, set up a testing pipeline, and added strong support for DDEV, which is Drupal's officially recommended local development platform. And what's more, the prototype chose several modules that are very likely to end up in Drupal CMS (Pathauto and Metatag being top examples).
When the Drupal CMS repository was created, it didn't seem wise to throw out all of that preexisting work and start from scratch. So the prototype code was renamed and copied into the Drupal CMS repository's `0.x` branch, with the intention that we would start with something that works, and iterate freely on that, rather than starting from scratch. This is in keeping with Drupal CMS's agile, rapidly iterative approach to development.
#### Does the Drupal CMS repository contain the definitive set of Drupal CMS recipes?
Which recipes exist in the Drupal CMS repository, and what they do, is completely up to the track leads. Recipes that came from the prototype are there as examples for track leads to examine, or change as they please, or even discard entirely. Be bold - slice and dice to your heart's content!
With that in mind, Drupal CMS _will_ be built as a "monorepo/manyrepos" project. This means that each recipe in Drupal CMS will be available as its own distinct Composer package, independent from all the others...but they will all be _developed_ within the same repository. This avoids a big pile of potential problems with dependencies, and other release management headaches. Symfony itself, for what it's worth, is developed in exactly the same way.
Yes. Drupal CMS is a "monorepo/manyrepos" project. This means that every recipe in Drupal CMS is available as its own distinct Composer package, independent from all the others...but they are all _developed_ within the same repository. This avoids a big pile of potential problems with dependencies, and other release management headaches. Symfony is developed in exactly the same way; even core uses this technique for certain things.
So yes, the Drupal CMS repository contains all of the Drupal CMS recipes, but the number of Drupal CMS recipes, and how they fit together, will change over time. Recipes, by their nature, have a lot of freedom to evolve.
So yes, the Drupal CMS repository contains all of the Drupal CMS recipes, but the number of Drupal CMS recipes, and how they fit together, may change over time. Recipes, by their nature, have a lot of freedom to evolve.
#### I see there's an install profile in Drupal CMS. How is this used? What does it do?
...
...
@@ -20,4 +10,4 @@ The Drupal CMS Installer is an install profile that exposes the ability to choos
The recipes that are part of Drupal CMS should, in theory, apply against _any_ install profile (although that won't necessarily always be the case; ideally all Drupal CMS recipes would apply cleanly against Standard and Minimal, but we don't yet enforce or test that).
The installer should be considered part of the overall infrastructure of Drupal CMS, and track leads should generally ignore it.
\ No newline at end of file
The installer is an internal part of Drupal CMS, but if you'd like to use its overall user flow and architecture for your own project, it has been split out into the separate [Recipe Installer Kit](https://www.drupal.org/project/recipe_installer_kit) package.
