[PD-dev] Thoughts on git & github workflows

[Dan Wilcox]

Howdy Miller and all,

Just some quick thoughts on git & github workflows for Pd.

Github is useful in that it makes contributing to a project's codebase easier without needing direct access using it's "Pull Request" mechanism. AFAICT, this is something *possible* using just git, but GitHub makes it relatively *painless*. I think it's great to see, at this point, many more people now contributing to Pd but, of course, how do we handle this?

Some observations/ideas:

1. Master branch as develop: The master branch is kept the same between the sourceforge "upstream" and the GitHub "mirror." So far we've managed to keep that true and Miller is the only one moving work from GitHub branches and PRs into "upstream."

2. Release schedule: Since we're on a yearly release schedule, with (possible) bug fixes after about 6 months, PRs and branches now build up on Github in the meantime. This is good. Mostly, we've managed to keep these relatively isolated from each other so they can apply cleanly. This is not always possible, however, for some things (for example, the recent const qualifier additions).

3. Merge order: I think what's important, then, is merge order. The smaller PR's that only touch unconnected files should be merged first. The larger PR's that touch *many things* should be merged later and, only after their author's have updated their branch by merging it with the now updated master. This should make things merge cleanly.

4. Using Github: The PR mechanism on Github also tools to gauge how the proposed changes will affect the codebase. The diffs and commit listing is useful as well as the result of the continuous integration build that IOhannes set up. You can basically see, at a glance, if the PR will merge cleanly or not. If everything is good, the easiest solution is really to use the green "Merge" button on the PR page, then pull those changes from the Github mirror to the upstream sourceforge repo. The push and pull can go *both* ways, with the addition of using the tools that make this easier. (If anyone is in the "I hate GitHub" camp, the same workflow is true with using Merge Requests in Gitlab.)

5. Feedback: As PR authors, we want to help you, Miller! If you're considering merging some work but want a few changes, no problem. Let us know in the PR discussion and someone will probably do it. Then we can make sure the PR branch is up to date and will merge cleanly. Again, the green "Merge" button is easy and useful here. Ideally, all you would need to do to integrate most things, is just hit "Merge" a few times and then pull the changes for the Github mirror.

6. Making changes: In my own Github projects, oftentimes someone gives me a PR which I want, but I will probably change a few details here and there. I usually handle this by merging it on the PR page, pulling, then making a cleanup commit later. This is usually easier than cherry-picking some commits and manually applying parts of others. Again, this works well for small things but not for larger stuff. In the latter case, giving feedback until you are satisfied with the proposed diff is the way to go.

7. Testing before merging: This is possible by adding the PR author's repo as a remote and then pulling whatever branch (master or otherwise) they submitted the PR with. This allows you to essentially do a checkout of their PR branch that you can build locally. I haven't needed to do it myself very often, but it has been useful in providing feedback and updates. There is also a mechanism to make commits to *their* branch before actually accepting the PR, but that's something more GitHub specific through their authentication setup.

--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20180911/468dfe90/attachment.html>