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

Wed Oct 28 16:48:15 CET 2015

It seems that we've got more issues than we can address before the
proposed 4.2 release date within the next few days - we're trying to
get this out in October.

Maybe it's time for another 'Major' release where we can remove more
than just the few mainboards and truly obsolete code that I was
thinking of when I started this conversation.

Is there anyone against removal of any of these boards/chipsets after
the 4.2 release, or should we wait for a decision about handling all
of the current issues before we delete anything?

   mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
   northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
 * arima/hdama - CPU: _AMD_SOCKET_940 NB: AMDK8, SB: AMD8111, SB: AMD8131
 * digitallogic/adl855pc - CPU: INTEL_SOCKET_MPGA479M, NB: INTEL_I855,
SB: INTEL_I82801DX
 * ibm/e325 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * ibm/e326 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * iwill/dk8s2 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * iwill/dk8x - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * newisys/khepri  - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2735 - CPU: INTEL_SOCKET_MPGA604, NB: INTEL_E7501, SB:
INTEL_I82870, SB: INTEL_I82801EX
 * tyan/s2850 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111
 * tyan/s2875 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8151
 * tyan/s2880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2881 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2885 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB:
AMD8131, SB: AMD8151
 * tyan/s2891 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
 * tyan/s2892 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
 * tyan/s2895 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
 * tyan/s4880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s4882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131

I'd vote against the removal of any of the AGESA codebases for this
release with the possible exception of the Family 12 codebase.  It's
only used in the torpedo mainboard, and even that's not well
supported.
I'd vote against the removal of any of the Intel FSP codebases for
this release.  They are recent, and they are definitely still being
used.  Even Rangeley.  Yes, they have their issues.

I could support moving platforms off to the 4.X branch if we decide to
create a 5.0 branch to move forward and get things cleaned up.  Still,
having dealt with several different forks of the coreboot code, my
opinion is that branching is basically going to end the support for
these platforms.  Of course the people that don't use those platforms
don't care whether coreboot is killed off for those platforms, so I'd
ask that these platforms that we're choosing to die be picked
carefully.

On Wed, Oct 28, 2015 at 8:30 AM, Aaron Durbin <adurbin at google.com> wrote:
> 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
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot