How to manage extensions

[aeronautes]

I'm curious about your thoughts on adding extensions to your dcs-scratchpad repo. Generally I'd like to provide more extensions to the user without further bifurcating the sourcing of scratchpad from the users perspective.

• Are you taking submissions for upstream pushes from forks? If so, how would you want maintainenance and development of those extensions handled in your repo?
• In particular I wonder when extensions have commits available often, how to deconflict that from your availability for review/merge. I'm aware of repo permissions or submodules as ways github addresses this type of issue.
• Would a more sophisticated system to allow on demand download of extensions be suitable to help decouple the development of extensions from their distribution from within the main repo?

[rkusa]

Good question. It would definitely be a good idea if extensions do not rely on me, as I often just do not find the time to look into PRs.

I am not opposed to having actively maintained extensions in the main repo. I would then probably add extension maintainers to the repo as contributors and enforce some PR review rules via a code owner file. E.g. a review from me is still needed if someone changes the core of the Scratchpad, and a review from the owner of an extension is necessary if someone changes that particular extension - but I wouldn't require a review from e.g. me for every extension change.
Realistically, I wouldn't accept every extension for such a setup and the decision of which extension to include and which not will probably very subjective – which might become a challenge.

The only other idea I have right now would be to maintain a list of links (and maybe screenshots) for extension in this repo as an entry point to be able to discover what else is out there.

Do you have a preferred approach that would work well for you?

(I expect to have some time later this month to get your open PR in)

[aeronautes]

The main point I'd like to support is a simple single method for discovery/install/upgrade of scratchpad and it's extensions. The current defacto method of download at this point would provide the indexing and distribution aspects. But managing new ones could be burdonsome depending on rate of addition. I have a couple on the verge of submission and a couple more in mind. There is the aspect of how to handle extensions that fall out of compatability. A versioning API could help prevent exposing compatability issues to users.

The link page would address indexing but would entail an extra layer of distribution and installation for the user. This could be addressed with a runtime feature in scratchpad to handle the download and install of an extension, but obviously someone would have to implement and maintain this.

As it stands the repo method seems the most preferable to me and if scaling becomes an issue revist it the future.