Move to Github completed and some issue

Nashif, Anas


We are now on github and PRs are flowing in, CI is operational as expected and we are getting used to the new flow.


Thank you for all who helped make this happen.


Now, we have been on gerrit for a while and we have been used to doing things in a certain way and a change in mindset is needed. Github has its own way of doing things and we need to adapt, one thing we immediately noticed is the fact that no everyone can add reviewers… This can only be done by users with write access to a specific repo. We are trying a few things to deal with that. In gerrit we used to add many reviewers using a script and we want to continue doing this using github APIs. In Github we have the concept of Assignee and Reviewers, we want to make use of that.


The other issue we are noticing is with subsystem branches, i.e. Bluetooth, net and ARM. Force push will not be possible if we decide to protect those branches and apply some rules on them and working around this through merges is not clean as well (leaves duplicate, phantom commits in the branch). We have tried to enable force push on the branches and removed protection, this results in PRs getting lots of unrelated commits when branches are rebased by maintainers.

This raises the question if in the github world we still need the subsystem branches on the main tree and if we should request all PRs to be submitted to master and have subsystem owners manage incoming changes to their subsystem on master, given that we have to go via  a fork anyways. To make it easier on maintainers of the various subsystem we can use the ‘project’ concept in Github and apply it to filter and triage pull requests and later issues if we decide to move to github issues in the future.


Moving all development to master has a few other advantages IMO. First, it is easy on new comers and occasional contributors, you do not need to figure out where to submit. There is only one entry point for all patches and changes. The other thing is the fact that when working on branches, those turn into isolated Silos of development with own policies and rules and end up in master as one large change. Finally, when developing against master and submitting changes to master we will keep master up to date all the time and there is no lag  in introducing features to master.


We had a lengthy discussion on IRC today about this but not everyone is on IRC, so posting this to get more views on the topic.






Join to automatically receive all group messages.