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

[Vladimir]

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.

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151028/8bae1dce/attachment.html>