Hello coding RIOTers, After I needed to rebase several PRs multiple times last week I’m really fed up with our current workflow. Furthermore, I discovered three things that show that we are in need of a more established workflow.
- our community is growing
- our master branch is changing constantly and has features in it that are sometimes thrown out the window weeks after they where introduced (e.g. radio_types.h or the older versions of netapi/netdev)
- we introduced feature-centric task forces to our communities
This is why I propose we change to a slightly adapted topic branch workflow (also known as feature branch) workflow [1]:
- the main RIOT-OS/RIOT repository will get the following branches
- master: points to the stable version of our latest release
- one stable branch for every major release (?)- devel: points to current development version (what is currently our master), hot fixes can be cherry-picked to the master from here.
- branching from devel: feature branch for every task force that is currently in active development, current changes will be merged regularly from devel by the branches maintainers- Pull Requests will be made either to devel (default) or the corresponding feature branch
- feature branches will be merged into devel if the feature reaches sufficient stability.
- devel will be merged into master, when a new release is out and master’s new HEAD tagged with the release number.
I observed two extra benefits from that:
- accidentally merged “SQUASH ME” commits can be squashed further upstream, before we add the commits to master or devel
- we can make maintenance of features more granular (and maybe solve our maintenance problem) by enacting the “Dictator and Lieutenants Workflow”, where the “Dictator(s)” are responsible for master and devel, and the feature branches can be maintained by the central persons of the Task Force (the Lieutenants). What do you think?
Cheers, Martine
[1] http://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows#Topic-Branches [2] http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow