[coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Aaron Durbin]

On Wed, Oct 28, 2015 at 7:59 AM, Vladimir <quickcracktime at gmail.com> 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 <pgeorgi at google.com> wrote:
>>
>> 2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me at 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
>> --
>> 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: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot