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

Wed Oct 28 16:53:09 CET 2015

IIRC I did the IBM e325/6 back in the day and I'm happy to see it die.

ron

On Wed, Oct 28, 2015 at 8:49 AM Martin Roth <gaumless at gmail.com> wrote:

> 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
>
> --
> 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/8db07597/attachment.html>