On Wed, Oct 28, 2015 at 7:59 AM, Vladimir <[email protected]> wrote: > On 10/28/2015 04:56 AM, Alex Gagniuc wrote: >> >> How will moving [AGESA] code [to a separate branch] affect supported [AMD] >> boards? >> > > The biggest problem here is: > > Various improvements and important bug fixes, that will be introduced to a > master branch and affect all the coreboot boards, will not be automatically > applied to that separate AMD branch. Those coreboot developers which have > AMD boards and want to constantly use and test latest and greatest coreboot > builds, they will have to constantly check the coreboot commit log and > backport all these improvements and fixes to their separate (and soon to be > abandoned) AMD branch. That will be adding lots of unnecessary manual work > and draining lots of workhours, which otherwise could have been spent on > writing the bug reports or improving a coreboot code which is common for all > the coreboot-supported boards.
Those developers should then take a more active role in improving the code that is applicable to them. As it stands now, I don't see any work going in improving those code bases. > > As result, moving AGESA code will affect - and not only AMD boards: all the > coreboot supported boards will be indirectly negatively affected by that > change... > > Luckily Timothy Pearson has advised a perfect solution for this issue: > > On 28 October 2015 at 02:23, Timothy Pearson wrote: >> >> Perhaps in the short term we can port the remaining AGESA Fam15h boards >> to native init, and look into moving Fam14h to as much native as >> possible while still keeping the PSP happy with its blobs? >> > > If the AGESA boards will be ported to a native init, they will be able to > continue to be supported by a master branch! That approach will allow > coreboot developers with AMD boards to avoid spending time on backporting > the changes and concentrate on developing and testing the latest coreboot > builds from a master branch There's more to it than just moving to native init. That doesn't remove the maintenance burden. > > Best regards, > Vladimir Shipovalov > > On 28 October 2015 at 11:32, Patrick Georgi <[email protected]> wrote: >> >> 2015-10-28 4:56 GMT+01:00 Alex G. <[email protected]>: >> > 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 >> -- >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg >> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: >> Hamburg >> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle >> >> -- >> coreboot mailing list: [email protected] >> http://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
