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 <gauml...@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 <adur...@google.com> wrote: > > On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi <pgeo...@google.com> > wrote: > >> 2015-10-28 14:50 GMT+01:00 Aaron Durbin <adur...@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@coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot