On 11/5/18 2:49 AM, Jaroslav Kysela wrote:
Hi all,
URL: https://github.com/alsa-project
I finally finished the first phase of the integration with GitHub. All repositories are now on GitHub and all repositories are mirrored to alsa-project.org. The github repositories are master (developers should push changes only to those repositories). If you refer the repository as the code source (for packaging or so), please, keep to use the repositories on alsa-project.org (in case when we migrate to other service in future like GitLab or so). The mirroring is realtime, so the changes should be visible on git.alsa-project.org in few seconds after the push.
I invited few people to the GitHub team and actually Takashi has full access to all repos, Vinod Koul should have the write access to tinycompress and Takashi Sakamoto should have the write access to alsa-gi. If I omitted someone (or someone is not on github), please, let me know (and register before).
Because github adds possibility for the pull requests and issue tracking, I added notifications for them to this (alsa-devel) mailing list. The short notification should be sent when an pull request or an issue is opened or changed. I think that it would be best to handle this per request, so the developer can ask to resend the patch to the mailing list for the wider review or just push the change with the signing.
I activated Travis CI for alsa-lib and alsa-utils and I will add other repos soon, too. URL: https://travis-ci.org/alsa-project
If you have some ideas which other github applications can be used to improve the code maintenance, let me know. I will probably play with the coverity checker (http://scan.coverity.com), too.
Nice. If you figure out how to do the CI integration with Coverity I am all ears. I've been trying to enable it for SOF (which is also on github) but couldn't find anyone that has done this successfully.
While I am at it, I've only used the 'rebase-and-merge' solution to merge PRs, which gives you a linear history similar to what we've always had. when using the default merge you end up with a spaghetti plate of branches that quickly makes no sense for most people and make tools like gitk nearly useless. Maybe the merge is fine when dealing with different subsystems but when dealing with relatively small components it's more confusing that helpful.
-Pierre