Switch issues and CI to GitHub

[Ansuel Smith]

>
> Hi all,
>
> Back at the Hamburg meeting in 2019 and a succeeding vote we decided to migrate over to a self-hosted GitLab instance. Some years passed and nothing really happened so I’d like to give this another go.
>
> None of the OpenWrt project members is willing to setup and maintain a GitLab instance and there were multiple vetos again gitlab.com.
>
> Our current bug tracker at bugs.openwrt.org is used by a minority of users (and devs), all community repositories (LuCI, packages, …) use GitHub for issue tracking. Instead of maintaining flyspray and the server, I’d like to export all flyspray issues, migrate them to GitHub and open GitHub issues for openwrt/openwrt to the public. A static or read-only version of flyspray could be hosted for the near future.
>
> Secondly I’d like to give the CI of the main repository another go. Our CI to build Docker images is currently on gitlab.com, I’d migrate that over to GitHub. Also I’d suggest to add similar CI checks as added to the packages (and routing and video and LuCI) repository. We could compile targets and tooling, check checksums etc, even build snapshots to lower the resource usage of our Buildbot infrastructure.
>
> During a recent _poll_ in #openwrt-adm multiple members liked the idea, however before doing or voting on anything, I’d like to ask for more comments.
>
> Thanks for all feedback,
> Paul

+1 for github. The complain about ethical gnu stuff seems a bit wrong
and IMHO doesn't really makes
sense. The only complaint about github is that it has some limitations
for CI and that it is run by ""evil"" MS.

Aside from that if used correctly Github is very powerful. Just check
some project like vscode or terminal
where you can set bot to quickly handle wrongly formatted issues or
pr. (I notice we have many)
Currently the system for reporting bug is problematic and most of the
time users don't even know it's a thing.
Also the priority and the tracking system is a bit wrong.

On top of that, moving importance to github would also makes devs care
more about pr on Github
instead of only checking the mailing list.
Using the mailing list is good for devs that mainly focus on kernel
and stuff but it's a nightmare for WIP or very big project like kernel
transition or platform change.

Another good tools that would benefit openwrt by using github is all
the project system or also the basic milestone thing. Would be good to
start creating an Issue that would summarize the target for a specific
release. That would massively increase the tracking of it and make it
clear where to focus.

In short, my idea is to try in every way possible to unify stuff and
start using more tools/feature to make it clear the current
development state.
There was a proposal of dropping the opkg upgrade stuff and move to a
"quicker" release phase (aka publish more version). It's a little OT
but I still think it's related to this kind of change. Using the
project/milestone feature would remove all the hassle of creating a
changelog/wiki entry/forum post for free as these minor releases will
be on github with a linked issue/milestone.

One small complaint I have is that I notice in the last few months a
bit of confusion of the main target for the next release. We have the
wiki page but we have no way to check the status.
Example:
- fw4 transition, we have a github issue but we were in a limbo for at
least a month and current situation is to set it by default to force
packages dev to update their package
- 5.10 transition, email on mailing list and issue on a dev github
page that got lost
- dsa transition, many wip pr no tracking
- ujail no idea but massive work under the hood by some packages?

I'm an active openwrt user and many times I find some difficulties
tracking the development state. Most of the time I check the git page
and watch feature magically appear but it would be good to have a
better tracking system and know what is the current direction of the
team.

In short, I'm very positive about a github migration but I really
advise to put some effort and make it the right way by giving
user/external devs more info about the current development state. (and
also introduce some bots to autoclose/auto alert user of bad pr/issue
to prevent any junk)