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

Aaron Durbin adurbin at google.com
Wed Oct 28 15:30:47 CET 2015

On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi <pgeorgi at google.com> wrote:
> 2015-10-28 14:50 GMT+01:00 Aaron Durbin <adurbin at google.com>:
>> 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.
> For one: when things are considered too inconvenient (and used and
> maintained) to be practical to keep around, remove them. For real.
> Claiming that we can stuff them "in branches" is a cop-out, because
> they're still dead.
> That's also why I proposed to go with tags for releases: When people
> are motivated enough to dig out the old stuff and make it work again,
> there should be some incentive to bring them up to current standards.
> Then they can get back into master.
> If somebody is spearheading such an effort and provides test
> resources, I think there's even some willingness to help with some of
> the more mechanical tasks - like cleaning out #include "file.c" stuff,
> but the motivation is rather hard to get by when it's unclear if the
> code is ever used again.

Where is that motivation now? There is no one providing the resources
so the answer is status quo which in turn means an insanely daunting
task in trying to clean up things that just so happen to touch 90% of
the mainboards because of the existing code flow/design. Without the
resources nothing can be done which means accumulation of cruft and no
idea if anyone uses anything. What's the end game there?

Maybe it doesn't matter because all the work required has been
completed going forward so one can just keep cranking out boards, but
I suspect that is not the case. And when another requirement surfaces
that no one was anticipating do we add yet another API/subset on how
to do things? Where's the common base to work against?

> People can still take any old commit (tagged, branched, or not) and do
> their own thing on github - however I think we're setting standards by
> what we do. Opening branches encourages to keep basing work on them,
> instead of considering snapshots to be just that.

What are the standards we're setting?

> My main objection to dropping things was that the motivation by the
> proponents always looked very similar to "this is inconvenient to me
> right now, let's get rid of this".
> If we were consequential in following up every such sentiment by
> everyone, we'd probably ship a single file, COPYING.

I think you're taking such a notion to the extreme. Probably the
superset of opinion may be that, but I don't think that's practical
nor helpful in this discussion. I've cited very specific things that I
have run into within my development, and I don't see a solution aside
from "tred lightly, hold your nose, and hope for the best". I'd be
happy to help support said improvement work, but there's no path for
such things, and the carrot of getting back into the sacred master
branch is apparently unpalatable for people.

>From my vantage point it seems people want the playground they grew up
with and knew and loved. Therefore, don't ever change my playground.

> 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

More information about the coreboot mailing list