I'd like to propose we discuss the possibility of taking kconfig and making it a git subtree under the Linux kernel. This would allow other projects outside of the Linux kernel to be able to update their own copy / fork of kconfig in a jiffie *very* easily. Why? kconfig has far outlived its own purpose as a modeling variablity language hack on the Linux kernel, and *is* forked and *used* by *many* projects, to the point I think ignoring its use outside of the Linux kernel is doing a disservice to its own growth. Counting just personal projects I have 3 projects which use kconfig alone. Last time I counted about 30 or so external projects. I'm confident this is a shy number of today's reality. Yes this does beg the question, that if this is done, can / should this be considered elsewhere. And yes, I'd like to hear the rants about why this would be a completely unacceptable practice *at all*. I've been using git subtrees now for another project and I'm *very* happy with it so far. It lets me keep a project with some code on its own git tree, and then multiple third party trees can embrace it, and decide to update later whenever they want. An example is the update_ssh_config [0] python script which I use on kdevops [1] for vagrant, but since it is also used for terraform and terraform uses modules I ended up sharing the code for terraform for its own terrarorm module [2] [3]. I do most development and unit testing on the main update_ssh_config git tree, and when I want to integrate its changes into kdevops I just run: make refresh This is because on kdevops I have: $ cat Makefile.subtrees # If you need to use a git subtree, please add it here. add-remotes: git remote add update_ssh_config https://github.com/mcgrof/update_ssh_config.git add-commits: git subtree add --prefix=playbooks/roles/update_ssh_config_vagrant/update_ssh_config update_ssh_config master refresh: git fetch update_ssh_config git subtree pull --prefix=playbooks/roles/update_ssh_config_vagrant/update_ssh_config update_ssh_config master Likewise for my terraform module, however there I just have these targets on my make Makefile. A person who first git cloned either the kdevops tree of the terraform module tree would first have to run the targets: * make add-remotes * make add-commits Today's process for updating kconfig on external projects requires substrantial manual oversight. [0] https://github.com/mcgrof/update_ssh_config [1] https://github.com/mcgrof/kdevops/ [2] https://github.com/mcgrof/terraform-kdevops-add-host-ssh-config [3] https://registry.terraform.io/modules/mcgrof/add-host-ssh-config/kdevops/latest Luis
