Dear RIOTers, due to me being the release manager for the first release after GitHub rolled out a bunch of new features I came a lot in contact with them. I thought it might be beneficial to share my impressions and opinions about these features and how we could utilize them as the RIOT community in the future.
TL;DR: the new features are great in general but have a few caveats primarily in easy usage. # Projects [1] This feature I utilized the most to organize the release. It basically provides a Trello-like cards-and-columns project management, that allows for adding pull requests and issues directly as cards. The column the card resides in and a link to the card will then be provided in the issue/PR (see e.g. PR 6082). The benefit is that this allows for a much more isolated organisation just in scope of the release (or e.g. a task force effort) than just milestones and issues could provide. Due to this feature it was little effort to draft some release notes from that. But they also come with a few drawbacks. First they are not directly linked to a milestone. E.g. adding an issue to the release project does not set the release milestone automatically, nor does the removal of the milestone remove it from the project. With a project as big as a release this quickly leads to confusion, if the assigned release manager does not stay on top of the game. Speaking of staying on top of the game: other than e.g. Trello no history of the cards, columns and the overall project is provided. Because of that, in a multi-user scenario things quickly might get lost (or lead to some surprises). There is also no way to change the project status of an issue from the issue directly. One always has to click on the current status (opening the link in the same window) and then has to manually change the status via drag-and-drop from one column to the next. All in all I see a benefit in using projects, even if it is just the direct link between issues/PRs and a project that makes it a little less fiddly and a little bit more transparent then e.g. working with an Excel table to organize the release. # Reviews [3] This is basically our time-tested review process formalized. A user can approve a PR, request changes or comment in bulk, but still can leave single comments without any review. All in all I think the feature is great! It integrates nicely into our established workflow and if a PR is approved it is far more visible than just a "looks good" instead of our formal "ACK". The drawbacks I could gather are rather nitpicky and just annoyances. First, GitHub changed the behavior of hitting Ctrl+Enter from leaving a single comment to giving a review comment. Since a review comment is only visible when the review is finalized (i.e. approval, change request, or in-bulk comment) it happened to me more than a few times (and from the comments of my colleagues at the office to them also) that I wrote a comment but nobody saw it for days, since I never finalized my review. The other issue some people had was that you only can approve a PR if you click on the "Files" tab of the PR, then "Review changes", then Approve. To me that is a logical GUI decision since one has to look at the code anyway to approve the code ;-) but I can see that less patient people might want to approve a PR in one click ;-). Lastly, you can't filter for approved PRs (yet) in the search bar (or at least the search terms are not documented by GitHub). A question that was raised by the introduction of this feature: Do we still need the informal ACK in our review process? # New integration methods of a PR We are now able to squash PR commits into one or rebase instead of merge them into master directly from the Web GUI. I don't know if and how well this handles merge conflicts, but I used it primarily to squash pull PRs where the authors did not react on the request to squash. Also a nice feature! # Required CI builds I think this is already a little older and was introduced with branch protection earlier this year, but I activated this for the 2016.10 release branch. I think this is helpful if Murdock does not pick up the PR for any reason, but of course if it fails for a random reason the PR is blocked. Another dimension to this is that one can choose to have the build always be up-to-date with the base branch. I chose this for RC1, RC2 and RC3 but it required unnecessary rebuilds when a PR was merged and another was basically already also build successful, but now needed a rebuild since 2016.10-branch had changed. What are your opinions/experiences so far? Kind Regards, Martine [1] https://help.github.com/articles/tracking-the-progress-of-your-work-with-projects/ [2] https://github.com/RIOT-OS/RIOT/pull/6082 [3] https://help.github.com/articles/about-pull-request-reviews/ _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
