Consider a name change to *-features

[jcbhmr]

Some 🧠 brainstorming ideas:

• It could be segmented so that there's different "sectors" of features, like:

  • devcontainers-community/language-features
  • devcontainers-community/meta-features -- things like "first-run-notice" or others?
  • devcontainers-community/tooling-features
  • devcontainers-community/npm-features
  • devcontainers-community/language-images
  • devcontainers-community/

• It could be an almost duplicate mirror of the official devcontaineres org with

  • features
  • images
  • templates

• Something else?

https://github.com/orgs/devcontainers-community/discussions/2#discussioncomment-5279357

Is this a good idea? Maybe, maybe not 🤷‍♂️

I know @eitsupi mentioned this as an idea somewhere?. I've split out discussion here.

[eitsupi]

Thanks for opening this up, I should also add the goal of getting around the workflow limitations of GitHub Actions.
https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits

That is, the number of concurrent executions is 20 and the size of the matrix is 256.

In order to avoid this limitation, I believe that even in the worst case, it is necessary to make a division like org/repo, org/repo2, org/repo3...
From this perspective, I think it is worth having multiple repositories, with a scope that keeps the repositories as bloated as possible.

If we do this, we will also need to have a custom template repository with forked https://github.com/devcontainers/feature-starter, etc. so that we don't have to configure CI every time......

[jcbhmr]

That is, the number of concurrent executions is 20 and the size of the matrix is 256.

related devcontainers-contrib/features#201

This is only important if you run each test in a parallel job. If instead you do them in parallel inside a single job or some other parallelization strategy, then it might work. Point is I don't think we should decide to splinter stuff because of technical limitations of GitHub Actions.

This isn't to say that segmenting feature repos is a bad idea, just that features1, features2, etc. for 256 features each seems distasteful to me.

[eitsupi]

This is only important if you run each test in a parallel job. If instead you do them in parallel inside a single job or some other parallelization strategy, then it might work. Point is I don't think we should decide to splinter stuff because of technical limitations of GitHub Actions.

This isn't to say that segmenting feature repos is a bad idea, just that features1, features2, etc. for 256 features each seems distasteful to me.

Good point.
Indeed, it's far easier to split a workflow than it is to split a repository!

[jcbhmr]

any further opinions, or are we good to close this as "Resolved" and stick with @devcontainers-communnity/features ? its not too late to change it yet!

im personally in favor of keeping it "features" to parallel and be inline with the @devcontainers/features repo naming scheme
🤔 but there could legit be a better way 🤷‍♀️

once #21 happens, this renaming thing gets a bit more difficult 😁

[eitsupi]

I think we should keep it that way for now. Close.