Move development to tmk_core repo and establish roadmap?

[njbair]

A Great Opportunity

TMK is getting to the point where more and more contributions are going to come in, which is wonderful! The more contributions this project gets, the better TMK can become. Better firmware will reach more users. And more users will mean even more contributors.

The Problem

It is confusing to have two repositories with essentially the same _tmkcore codebase.

It is important for everyone's sanity, especially @tmk, that everybody clearly understands how to contribute to the project.

My Proposed Solution

I propose that all new development for the core codebase should happen in the _tmkcore repo. The _tmkkeyboard project can pull in _tmkcore as a subtree.

Development and Release Branches

@tmk, you have mentioned keeping _tmkcore as the "stable" release, and doing the heavy development inside _tmkkeyboard. Keeping the development and stable versions separate from each other makes a lot of sense, and I think it's a wise move.

You can accomplish the same separation in the _tmkcore repo alone, by using GItHub Releases and/or Git Tagging. Here is a very good Git branching model for maintaining projects with lots of contributors, which I am using successfully on another project.

For contributors, the separation is clear:

• If you are contributing core code, submit your PR to the _tmkcore development branch.
• If you are contributing project-specific code, submit your PR to _tmkkeyboard.

For users, the separation is clear:

• If you are starting a new project, pull in _tmkcore as a dependency.
• If you just want to build or slightly modify an existing project in the TMK collection, download or clone _tmkkeyboard.

  Other Benefits

• Encourages better documentation of changes. Release tags make it easy to track changes without the need to scan diffs line-by-line. If you need to see what keyboard.c looked like before Feature X was added, just review the change log and find the relevant release number, then pull up that tag in Git.
• Provides a framework for organization. GitHub can be assigned to Milestones corresponding to release versions, so everyone knows what to expect from a new release, and contributors know what outstanding items are holding up the next release.

  Conclusion

These changes would provide the TMK project with some much-needed organizational structure, which could help potential contributors determine the best ways to get involved.

I, for one, would love to help out however I can. I believe others would (and have) as well. Establishing a release schedule/roadmap would be a step towards enabling those folks to get involved.

[tmk]

Thanks @njbair, I agree, people who are interested in strarting their own project can/should use tmk_core. And tmk_keyboard will be used mainly by TMK product users of HHKB Alt Controller and keyboard converters.

I also think tmk_keyboard is just one of users of tmk_core but very lazy to make a PR/contribution for the upstream repo just like most of other users :D My problem is I'm not familar with git subtree much and its operation is not intuitive in comparison with git submodule. To make patch for tmk_core repo from subtree tmk_core of tmk_keyboard is very tedious.

It also includes good resourse links to read, I read some of them before but I didn't understand or just can't remember the content :D I'll check them.

[njbair]

@tmk the problem with git submodule is that every user has to learn the submodule commands. With git subtree, only contributors have to worry about it. And it's not that hard. I know the commands by heart now, after only messing around with subtrees for a few months. By contrast, after several years of use I never felt like I truly understood what git submodule was doing.

If it would help, I can write some shell scripts to automate the subtree push/pull process. Let me know what you think.

[tmk]

True. And I think some of users download zip archive to get source code and they don't even have git command. To include tmk_core source in the archive I had to use subtree. I didn't want users to download tmk_core separately.

I know people say subtree is better but I didn't see problems on submodule in my usage. Thanks for your offer, but I have to learn it and know what I'm doing. subtree always make me nervous :D

[njbair]

It's easy once you learn it. I keep this guide bookmarked.

There is still the matter of Pull Requests. All of the PR's in this repo actually are for tmk_core. What do you think about the idea of moving development over to the tmk_core repo, and maintaining separate branches for development and stable? Then you can just git subtree pull the appropriate branch into the tmk_keyboard repo.

[tmk]

Now tmk_core has develop branch, I'll try to update it with my working tree as possible. Not sure this is on the way you proposed but let's see how it works.