<div dir="ltr">IIRC I did the IBM e325/6 back in the day and I'm happy to see it die.<div><br></div><div>ron</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 28, 2015 at 8:49 AM Martin Roth <<a href="mailto:gaumless@gmail.com">gaumless@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It seems that we've got more issues than we can address before the<br>
proposed 4.2 release date within the next few days - we're trying to<br>
get this out in October.<br>
<br>
Maybe it's time for another 'Major' release where we can remove more<br>
than just the few mainboards and truly obsolete code that I was<br>
thinking of when I started this conversation.<br>
<br>
Is there anyone against removal of any of these boards/chipsets after<br>
the 4.2 release, or should we wait for a decision about handling all<br>
of the current issues before we delete anything?<br>
<br>
   mainboard/via/epia-m700 - <a href="http://review.coreboot.org/#/c/7470" rel="noreferrer" target="_blank">http://review.coreboot.org/#/c/7470</a><br>
   northbridge/via/vx800 - <a href="http://review.coreboot.org/#/c/7471" rel="noreferrer" target="_blank">http://review.coreboot.org/#/c/7471</a><br>
 * arima/hdama - CPU: _AMD_SOCKET_940 NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
 * digitallogic/adl855pc - CPU: INTEL_SOCKET_MPGA479M, NB: INTEL_I855,<br>
SB: INTEL_I82801DX<br>
 * ibm/e325 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
 * ibm/e326 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
 * iwill/dk8s2 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
 * iwill/dk8x - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
 * newisys/khepri  - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
 * tyan/s2735 - CPU: INTEL_SOCKET_MPGA604, NB: INTEL_E7501, SB:<br>
INTEL_I82870, SB: INTEL_I82801EX<br>
 * tyan/s2850 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111<br>
 * tyan/s2875 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8151<br>
 * tyan/s2880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
 * tyan/s2881 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
 * tyan/s2882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
 * tyan/s2885 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB:<br>
AMD8131, SB: AMD8151<br>
 * tyan/s2891 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131<br>
 * tyan/s2892 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131<br>
 * tyan/s2895 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131<br>
 * tyan/s4880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
 * tyan/s4882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131<br>
<br>
<br>
I'd vote against the removal of any of the AGESA codebases for this<br>
release with the possible exception of the Family 12 codebase.  It's<br>
only used in the torpedo mainboard, and even that's not well<br>
supported.<br>
I'd vote against the removal of any of the Intel FSP codebases for<br>
this release.  They are recent, and they are definitely still being<br>
used.  Even Rangeley.  Yes, they have their issues.<br>
<br>
I could support moving platforms off to the 4.X branch if we decide to<br>
create a 5.0 branch to move forward and get things cleaned up.  Still,<br>
having dealt with several different forks of the coreboot code, my<br>
opinion is that branching is basically going to end the support for<br>
these platforms.  Of course the people that don't use those platforms<br>
don't care whether coreboot is killed off for those platforms, so I'd<br>
ask that these platforms that we're choosing to die be picked<br>
carefully.<br>
<br>
<br>
<br>
On Wed, Oct 28, 2015 at 8:30 AM, Aaron Durbin <<a href="mailto:adurbin@google.com" target="_blank">adurbin@google.com</a>> wrote:<br>
> On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi <<a href="mailto:pgeorgi@google.com" target="_blank">pgeorgi@google.com</a>> wrote:<br>
>> 2015-10-28 14:50 GMT+01:00 Aaron Durbin <<a href="mailto:adurbin@google.com" target="_blank">adurbin@google.com</a>>:<br>
>>> That presupposes there is work going on in those branches that is<br>
>>> desired to be pushed back into another branch. Anyone can very much<br>
>>> port forward something if they so choose. That's the point of the<br>
>>> branching mechanism.<br>
>>><br>
>>> What is your proposal for dealing w/ inconvenience? I haven't seen a<br>
>>> modicum of change in that area. In fact, what we have seen is more<br>
>>> boards being added that use the constructs that are inconvenient.<br>
>> For one: when things are considered too inconvenient (and used and<br>
>> maintained) to be practical to keep around, remove them. For real.<br>
>> Claiming that we can stuff them "in branches" is a cop-out, because<br>
>> they're still dead.<br>
>><br>
>> That's also why I proposed to go with tags for releases: When people<br>
>> are motivated enough to dig out the old stuff and make it work again,<br>
>> there should be some incentive to bring them up to current standards.<br>
>> Then they can get back into master.<br>
>> If somebody is spearheading such an effort and provides test<br>
>> resources, I think there's even some willingness to help with some of<br>
>> the more mechanical tasks - like cleaning out #include "file.c" stuff,<br>
>> but the motivation is rather hard to get by when it's unclear if the<br>
>> code is ever used again.<br>
><br>
> Where is that motivation now? There is no one providing the resources<br>
> so the answer is status quo which in turn means an insanely daunting<br>
> task in trying to clean up things that just so happen to touch 90% of<br>
> the mainboards because of the existing code flow/design. Without the<br>
> resources nothing can be done which means accumulation of cruft and no<br>
> idea if anyone uses anything. What's the end game there?<br>
><br>
> Maybe it doesn't matter because all the work required has been<br>
> completed going forward so one can just keep cranking out boards, but<br>
> I suspect that is not the case. And when another requirement surfaces<br>
> that no one was anticipating do we add yet another API/subset on how<br>
> to do things? Where's the common base to work against?<br>
><br>
>><br>
>> People can still take any old commit (tagged, branched, or not) and do<br>
>> their own thing on github - however I think we're setting standards by<br>
>> what we do. Opening branches encourages to keep basing work on them,<br>
>> instead of considering snapshots to be just that.<br>
><br>
> What are the standards we're setting?<br>
><br>
>><br>
>> My main objection to dropping things was that the motivation by the<br>
>> proponents always looked very similar to "this is inconvenient to me<br>
>> right now, let's get rid of this".<br>
>> If we were consequential in following up every such sentiment by<br>
>> everyone, we'd probably ship a single file, COPYING.<br>
><br>
> I think you're taking such a notion to the extreme. Probably the<br>
> superset of opinion may be that, but I don't think that's practical<br>
> nor helpful in this discussion. I've cited very specific things that I<br>
> have run into within my development, and I don't see a solution aside<br>
> from "tred lightly, hold your nose, and hope for the best". I'd be<br>
> happy to help support said improvement work, but there's no path for<br>
> such things, and the carrot of getting back into the sacred master<br>
> branch is apparently unpalatable for people.<br>
><br>
> From my vantage point it seems people want the playground they grew up<br>
> with and knew and loved. Therefore, don't ever change my playground.<br>
><br>
>><br>
>><br>
>> Patrick<br>
>> --<br>
>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg<br>
>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg<br>
>> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle<br>
><br>
> --<br>
> coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
> <a href="http://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="http://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a></blockquote></div>