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

[Aaron Durbin]

On Wed, Oct 28, 2015 at 3:32 AM, 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.
>

That presupposes there is work going on in those branches that is
desired to be pushed back into another branch. Anyone can very much
port forward something if they so choose. That's the point of the
branching mechanism.

What is your proposal for dealing w/ inconvenience? I haven't seen a
modicum of change in that area. In fact, what we have seen is more
boards being added that use the constructs that are inconvenient. From
the few years that I have been involved in this project I have seen
the airplanes pile up in the graveyard. So basically, it seems like
status quo rules. Or the time horizon for change is so long (10 years)
that the result is accumulation of more cruft? To add insult to injury
there's no tenable way of making changes in these areas because the
physical resources are not readily available to test against. As such
there is no progress in fixing those inconveniences which in turn
means an ever increasing burden for making non-periphery changes.

Ignoring the #include "file.c" constructs, a large majority of the
mainboards drive romstage flow entirely within those directories. i.e.
main() starts in mainboard. There is no common/consistent flow for
romstage on x86. That requires chipset as well as mainboard changes to
rectify. How do you propose one goes about doing that? Build test it?
Then have someone come 6 months later and say "hey, this doesn't
work."

> tl;dr: hiding problems in branches won't serve us long-term.

What does serve us long-term? And what are those goals? Is it
quantifiable by the number of mainboards checked into the coreboot.org
repo that build regardless of the maintenance burden?

>
>
> 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