Greetings fellow geeks. We want your contributions to the Cypress code base. Let’s talk about how Cypress, an Infineon Technologies company, uses GitHub. I am one of the owners of our GitHub presence. So you’re talking to the right person. I want your feedback on our pull request process.

In this article I talked about how the ModusToolbox build system locates and copies libraries of code. It is phenomenally powerful and flexible, and we put all that code on GitHub. We’re approaching 400 repos and growing. Every board support package, code example, and library sits on GitHub. Even the ModusToolbox™ build system is on GitHub. With very few exceptions you get the source code, not a binary.

In the classic model for software developers, the GitHub repository is the source of truth! Projects are shared. There is a community of contributors, and what is on GitHub is the code base. There are often multiple development branches in a repo. There are maintainers who review and approve pull requests. Approved changes are merged into the master branch on GitHub. You can get the bleeding edge in some development branch, or a stable release from the master branch or the release page for the repo.

We differ in one significant detail. We develop our code internally and deliver it on GitHub. The Cypress source code you see on GitHub is not the source of truth. That’s internal. In an open source project you will see development branches. You won’t see those in a Cypress GitHub repository.

Nonetheless, you can still contribute. We support pull requests (PRs). I defined a process that blends how we work internally with the GitHub pull request model. So if you have an idea or see a defect, you can and should contribute. You can read about our workflow here. https://github.com/cypresssemiconductorco/.github/blob/master/CONTRIBUTING.md.

Because you don’t have write access to our repos, you fork the repo, make changes in your own fork, and then create the pull request by comparing across forks. Meanwhile, our code is progressing behind the firewall, so you can’t see the very leading edge of code development. We handle that problem in the PR review. When you read CONTRIBUTING.md you’ll see the suggestion that, especially for anything extensive, talk to us first. Raise an issue and propose what you’re going to do. Your contribution might be timely and wonderful, and we will leap at it. Or we may already be on it, and we can save you some work. Either way is a win-win.

Our support team monitors all the repos and handles issues, answers questions, and manages the initial back and forth on a PR. A PR of course is typically escalated into the engineering team. An engineer will review the pull request. When approved we pull your code behind the firewall, merge it into our internal systems, and make sure you get credit when it’s released. This is what we’re shooting for.

approved.png

Image credit: Who knows? It's a meme!

I’d like your thoughts. I hope we have captured the essence of GitHub, which is community contribution and collaborative development. Our GitHub PR process is relatively new so, truly, your feedback is most welcome.

Let me know what you think. If I can make it better, I will.