waldobronchart/ShortcutMapper

Extract into two repos?

dhc02 opened this issue · 6 comments

Just an idea: the submodule thing (and maintaining the codebase in general) becomes less awkward if you're calling a separate repo as a submodule rather than a different branch of the same repo.

So how about two modular things able to be contributed to separately: a front end (currently gh-pages) and a back end (currently master)?

I'm really not sure what the best approach is, but I like that this is being discussed.

Are there any examples of how other people are doing it?

I'm going to try forking, making a change and then applying it back onto the main repo and see what the process is like.

Ok i've tested this and submitting a pull-request on the master branch is problematic.

I think I'm just going to merge everything into gh-pages branch and then use that one as master.

So I admittedly haven't had time to peruse the code yet, but I think there's real potential in separating this into two apps, essentially:
A: a client-facing app that displays different information sets overlaid on an interactive keyboard, and
B: an API-only app that organizes and provides the information used by app A via API calls

Down this path also lies the possibility of allowing app B to accept new and updated keyboard schemas through some sort of public-facing interface rather than having them be part of the core codebase.

I'll dive in tomorrow and take a look.

Currently the exporters know exactly where to export their data to, given the standardized layout of the repo with the submodule.

I worry that by splitting it up into multiple repo's, it's going to be:

  1. needlessly complicated for people who want to contribute small quick changes (one line changes that fix shortcuts that were incorrectly mapped, for example)
  2. hard to enforce a standardized layout (where do the exporters export to?)
  3. pull-requests with changes in both the exporters and the site are split up

I've created a gh-pages-reorg branch with everything merged into one like I mentioned previously. I'm going to do some tests with forking that and see if it's acceptable.

Check it out here:
https://github.com/waldobronchart/ShortcutMapper/tree/gh-pages-reorg

Ok so I've done this now. The repo has one main branch called gh-pages where everything lives.

For reasons I mentioned earlier, I think this is the least confusing option.

I appreciate your input very much :)

I'll add that it can always be changed later on - nothing is set in stone.