OpenWrt and GitHub

[Paul Spooren]

Hi all,

After a request by some developers in #openwrt-devel I added a 
Signed-off-by check (DOC) to our GitHub presence, since it's one of the 
most common formal issues. This is a handy piece of CI to waste less 
human time in reviews.

Speaking of more CI, it's been two nearly two years since Lynxis and 
mine idea to bundle up things to a self hosted GitLab instance rather 
than using a wild mix of tooling[1]. Since then some things happened, 
but the overall the situation is the same as two years ago. Nobody seems 
keen to setup and maintain a GitLab instance for OpenWrt.

Should we stall that plan and reevaluate if a (temporarily) gitlab.com 
hosted instance is the better way to proceed?

Next to CI, the issue tracking is a bit of a mess. In theory everything 
should go to bugs.openwrt.org, but since it doesn't support a lot of 
bells and whistles users distribute their issues to the forum and GitHub 
commit comments[2].

Could it make sense to use the GitHub issues rather than Flyspray? 
Different from Flyspray the GitHub issues support an API, CLI and also a 
way to export issues, unlike Flyspray where it needs HTML parsing or SQL 
plumbing.

I'm not a fan to freely promote a commercial service but since nobody is 
excited about doing extra administrative work on a GitLab instance, why 
not? We relay on commercial entities anyway (e.g. Hetzner) and migrating 
a VM from provider A to B might just be as annoying churn as plumping 
"old service API" to "new service API".

tl;dr: Use GitHub issues instead Flyspray? Use GitLab.com with some CI? 
Do nothing?

Best,
Paul

[1]: 
https://openwrt.org/meetings/hamburg2019/start#defragmentation_of_code_and_tools
[2]: 
https://github.com/openwrt/openwrt/commit/2cd1a108290f48fd35373f91056c05277c289687