* Martin Roth gaumless@gmail.com [151026 22:51]:
I'd like to start a discussion about boards, chipsets, drivers, or other code that can be removed from the tree.
At the coreboot conference in Bonn, we discussed this some. I believe that we decided to wait until the next release/branch of the coreboot tree before removing anything. By planning ahead and deleting the components immediately after the release, we can list the things that have been end-of-lifed in the branch release notes.
By discussing this on the mailing list instead of just pushing commits to the tree, we can get better buy in from all interested parties.
I'd request that these be boards & chips that are no longer being produced, and haven't been updated in a few years.
These seem like good candidates to start the discussion: mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470 northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
As far as I can tell, the last real contributions to these came in 2009 - all the changes since then have been cleanup and modifications for other changes across the coreboot tree.
Since 2009 is really only 6ys ago, I'm a bit hesitant about the VX800 stuff (while leaving the older CN700 / CX700 in the tree) It also seems VIA gave up on coreboot at this point, so it might not matter, unless we want to work on bringing them back?
Is anybody in contact with VIA at this point?
What other directories should be removed from the tree after the next release?
I want to add the following boards (and their chipsets and super ios) that have been in the tree and basically unmaintained for 10+ys:
* arima/hdama * digitallogic/adl855pc * ibm/e325 * ibm/e326 * iwill/dk8s2 * iwill/dk8x * newisys/khepri * tyan/s2735 * tyan/s2850 * tyan/s2875 * tyan/s2880 * tyan/s2881 * tyan/s2882 * tyan/s2885 * tyan/s2891 * tyan/s2892 * tyan/s2895 * tyan/s4880 * tyan/s4882
Eventually it would be nice to be able to use submissions to board-status repo to determine what's being used. We're just not at that point yet.
I think this is a hard problem. Churn on a board's or chipset's code does not necessarily coincide with a board being used or the other way around. A target might just be stable and working well.
We need to get to the point where 100% of the boards in the tree are boot tested 100% of the time.
Stefan