Removal of projects or separation of core library and project

[tmk]

I have plan to remove some of projects which I can't mainatain from repository, or move projects to another(each own) repository.

1. Most of converter projects will continue to be updated by hasu/tmk(me) because I still own keyboards needed to test firmware. Meanwhile most of keyboard projects can't be tested. hasu/tmk owns keyboard pojejcts; gh60, hbkb, hhkb, infinity, onekey and onekey_mbed. But they may be separated from core library.

2. If contributor of the project has a repository it should be center of the project. README of tmk_keyboard just has a link to the repository and tmk_keyboard has no code for the project. Place your repository link on this wiki page: https://github.com/tmk/tmk_keyboard/wiki/TMK-Based-Projects

Update:
2016/01 Moved some projects to orphan directory now. 649151c

[xauser]

I can offer to test the following keyboard projects: kitten_paw, kmac, lightpad, lightsaber, nerd and phantom.

[tmk]

Thanks.
Probably I'll contact you when I make decision about this.

[p3lim]

What about turning it the other way around?

Currently the keyboards and converters are stored in directories within the firmware, but what about having each keyboard/converter it's own project (repository) and have tmk_keyboard be a submodule within those.

It will require some restructuring for sure, but it's one way of cleaning all of this up.

[p3lim]

I would also like to suggest that you make an organization instead of having all of this on an account.

This allows easier contribution and the possibility for teams and hosting keyboard/converter projects all in one public space instead of having everything scattered across different accounts/users (although still being possible for those who want)

[BenBergman]

An organization with a main repo for the core code and separate repos that reference the core (perhaps through subtrees or submodules) would be a great way to organize all the related projects. I think you can grant different permissions to different repos in an org, so you can give people access to maintain their own keyboard projects without letting them touch the core, if you wanted to do something like that.

[p3lim]

I think you can grant different permissions to different repos in an org, so you can give people access to maintain their own keyboard projects without letting them touch the core

That is correct, and exactly what I suggested 😄

[xauser]

I wouldn't split up the tmk project in any kind of way. Having all drivers in one project is very convenient for me. Of course, no single person can test all incoming patches alone because of the required hardware, that's why I would assign a maintainer to each keyboard project/subtree. Patches to those projects/subtrees would go from maintainer to tmk project only.

[kejadlen]

A separate org with one main project with submodules for individual drivers makes sense to me.

[nemith]

A single repository can be beneficial as well. For example code refactoring means a single commit to touch every consumer of a library call vs a commit for each sub repository.

[p3lim]

A single repository can be beneficial as well. For example code refactoring means a single commit to touch every consumer of a library call vs a commit for each sub repository.

Which means one person (hasu) would essentially have to either update all of the drivers himself or validate and merge changes from others, equal amount of work.
If we have a main project treated as a submodule it won't be updated unless the repository owner/maintainer of the driver does so, which also means that nothing will be broken if the main project changes, and leaves the owner/maintainer to update the driver if necessary.

I wouldn't split up the tmk project in any kind of way. Having all drivers in one project is very convenient for me. Of course, no single person can test all incoming patches alone because of the required hardware, that's why I would assign a maintainer to each keyboard project/subtree. Patches to those projects/subtrees would go from maintainer to tmk project only.

Having one test driver in the main project could be used for both testing and maintaining what would be considered "the basic implementation" that drivers could refer to for changes. This test driver could also be heavily commented for this exact reason.
Which driver that would represent would be up to hasu, I'd guess the GH60 driver.

[BenBergman]

@p3lim ++