@zebra, yes it’s awkward. But on the flip side, it’s code used across 6 different products (7 if you count Orca), so a bit of awkward is to be expected. I think there are 2 ways to go about it.
The first is as you stated.
libavr32 changes and push them to catfact/libavr32.
- Fix each module, best to keep the change atomic, so change the code and update the submodule commit (
git add libavr32) in the same commit.
- Open a PR again monome/libavr32. Merge it.
- Open PRs against each of the modules.
One point, if you want to pull the
libavr32 changes from
teletype you don’t have to go via GitHub, you can pull and push across the filesystem instead.
The other option is to not update the modules, but instead defer those changes until such a time as a
libavr32 update is required. At the moment there is no reason why (e.g.) White Whale needs a new version of
libavr32, maybe it will when an update to the
ii protocol comes along. It would probably be a nice courtesy to open up an issue in each module’s repo though.
Either way, I think adding a
CHANGELOG.md file to libavr32 would be a very good idea, drawing a lot of attention to breaking changes, also best to include the word
breaking in the commit message somewhere.
Finally, I’d humbly suggest that if you’re going to make a breaking change it would be best done in isolation from any other changes, you should be able to create a new branch from upstream
chery-pick the commit.
I’m not sure if you’re aware but monome/libavr32 has a .travis.yml script set up that checks the
master branch of each module against any changes made. If you log in to travis you can enable it on catfact/libavr32 too. Then you’ll get notifications of build failures in the other modules due to any changes made, you may or may not find this useful. We could add Aleph to the list of build checks once you’re ready? (I need to add Ansible too.)
I’ve noticed you’ve made some changes in the
asf folder, would it be possible to have a think if that’s the right thing to do. I wrote a script to generate the contents of that folder from Atmel’s zip file (and make any patches). The thinking was that it would be easy to update if a newer release of the ASF came along (or if we want to add any extra files). Now I admit it’s pretty unlikely that Atmel will update the AVR32 side of the ASF, but I think we should formally acknowledge if directly editing the contents of the
asf folder is okay.
My feeling is that it would be better to update the diet-asf scripts and use that, but I have zero responsibility towards any of this, so I will defer to yourself and @tehn and try to be as helpful as I can however you want to go about it.