Am Do., 29. Nov. 2018 um 11:59 Uhr schrieb Mike Banon mikebdp2@gmail.com:
I think, while Jay's board stays upstream it is benefiting from the "universal improvements": great commits to ./payloads/ ./util/ and also to the "not-MB-specific" parts of ./src .
And any of these changes (in particular to src) can break the board. It probably is already broken in master.
If his board will be removed from upstream he will have to track all these improvements and "copy/paste" them to his local repo - this will result in extra maintenance on his part and significantly lower his desire to contribute.
On the other hand, it is ensured that the tree he creates is working (simply because he'll test the commits he imports). I'm not a fan of that development model though. (it's the old copy&paste BIOS model that leads to stagnation).
Ideally he'd be testing master with some regularity and fix (or at least report) issues as they pop up. Arthur already started providing patches to retrofit the features he proposed should be mandatory in 6-12 months. Once these are sorted out, Jay's chipsets are off the hook!
We can easily make the support for Jay's boards in coreboot keep on building - we can't easily test that we're just carrying along non-functional bits.
That's where the "remove boards from master" movement is coming from: Truth in advertising, in that instead of claiming that we support 200 boards of which 180 were built with a tree from 3 years ago, we have a rather good idea what does. Both by taking the board-status system into account, and by dropping code paths that nobody-who's-testing uses anymore.
Right now you're just reiterating that us spending work on keeping boards in the tree is a nice service to Jay. Thanks, but we're well aware. Can you also convince us that it's a good service to the users of Jay's boards who expect master (and any future release) to work, given that there's code for boards of that specific name?
(Jay, sorry for singling you out like that)
Regards, Patrick