2015-10-28 4:56 GMT+01:00 Alex G. mr.nuke.me@gmail.com:
Here's a list of things I think should be moved to branches, right after the 4.2 release:
So far the idea was to drop things in master after a release, and create branches for releases (as I did for 4.1 yesterday, in addition to the tag). So, when dropping stuff after the 4.2 release, to go back to these things, you start from the 4.2 branch.
Now remember, this assumes branches are as first class citizens as 'master'. Look at chromiumos coreboot: plenty of branches. That shows it can work.
There's a significant difference (and a problem that we'd inherit by adopting the chromium gerrit model):
The difference is that Chromium firmware branches are made per-board for devices where not many changes are expected. The items you point out are most interesting for adding new boards (nevermind if this actually happens - but the Lenovo *60 stuff wasn't predicted a year before it happened either, 945 was "dead" then). If we go for branches for that, developing FSP1.0 coreboot will look quite different from master-coreboot.
The problem we have with firmware branches over at Chromium is that, as far non-ChromeOS development is concerned, branches are where commits are pushed to die. They're not folded back into mainline Chromium nor coreboot.org. We don't really have a good solution for that.
If we spawn tons of branches every time something becomes a bit inconvenient to deal with, we're quickly devolving into u-boot: vendors will just start maintaining their own branches, and porting high level features between those requires an immense amount of effort because there are many years of divergence between them. If you want a taste of that, try building something on Chromium's chromeos-2013.04 branch and then port it to upstream master. And that was just 2.5 years.
tl;dr: hiding problems in branches won't serve us long-term.
Patrick