Existing development and maintenance workflows for OpenBMC

[Andrew Jeffery]

Ed's thread on rearranging the way we maintain OpenBMC as a whole[1] tries to tackle multiple problems but is primarily aimed at solving difficulties with workflows.

Rather than carry on discussion of the advantages/disadvantages of a monorepo here I thought it might be useful to point out how some of us go about working with OpenBMC as it exists today. To that end there a few blog posts:

## Day-to-day development workflows

1. http://www.stwcx.xyz/blog/2021/04/18/meson-subprojects.html
2. https://amboar.github.io/notes/2022/01/13/openbmc-development-workflow.html

What does your day-to-day development workflow look like?

How do you share your work prior to getting it merged?

## Long-term maintenance workflows

3. https://amboar.github.io/notes/2021/09/16/history-preserving-fork-maintenance-with-git.html

How do you/does your company maintain its internal OpenBMC fork(s)?

At IBM we use a separate (internal and external) Github org where we mirror the upstream repositories. We apply commits to these forked repos via Github PRs against a non-master branch that has a consistent name across all the repos. For a (large?) number of cases these forks are rebased against the upstream repos using the technique in 3. The bitbake recipes are then adjusted to point at the forked repos.

Andrew

[1] https://lore.kernel.org/openbmc/CAH2-KxAJS_U8=meCxp8ue7n0bmnzeRpyZOPZpy0h1cFEbbz-HA@mail.gmail.com/