We have been working on our custom version of the firmware for a bit over a year now.
We want to stay up to date with the latest stable version but I’m not sure if our workflow to update is optimal. I’m looking for guidance on the best practices in terms of maintaining a custom firmware version?
Currently our custom code branches off release/v1.10 we would like to v1.11 but rebasing our branch on v1.11 seems not straight forward. There are conflict on files that we haven’t touch as well as on every submodule changes.
So, I tried rebasing release/v1.11 on release/v1.10 and run in the same conflicts. Rebasing with -Xtheirs did help a bit but still I aborted. I’ve then tried merging release/v1.11 on to release/v1.10 and it worked almost seamlessly except for deleted files (as expected) and some submodule (unexpected).
I haven’t went further about bringing our branch up to date.
At the git level all I can really suggest is a good three-way comparison tool (Beyond Compare, Meld, etc) and possibly merging instead of rebasing. Rebasing can be great to cleanly carry a small number of changes on the tip of a branch, but for larger projects I’ve found merging to almost always be easier overall.
Within PX4 itself I’m interested in things we could do to make it easier (or at least not impossible) for forks to stay in sync with new releases. From my perspective this starts with a continuous effort to make (and keep) things modular and self contained. It depends on the specific situation, but in many cases I would encourage forks to carry their code in custom modules (or custom boards) rather than changing things in place.
If you can share more details about the general nature of your changes I’d be happy to discuss more specifics and see if there’s anything we can do.
Does the idea of “forking” at the module level help in your situation?
Do we need more clearly defined interfaces for what a certain type of module must do?
If there are common areas of customization we could add hooks for custom code.
Which areas have been most problematic during the update?
Do you need more granularity in disabling existing functionality? (build time or run time configuration)
Are any submodules particularly problematic for carrying customizations?
If you have little changes outside of your core IP (bug fixes, etc) I would strongly encourage you open pull requests as you go. In many situations the best compromise I’ve seen is helping to mold baseline PX4 into what you need (stable, extensible, etc) while carrying the bulk of your code in custom modules.
