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@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@google.com wrote:
On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi pgeorgi@google.com
wrote:
2015-10-28 14:50 GMT+01:00 Aaron Durbin adurbin@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