Hi Marshall,
thanks for that cohesive report and insight into your development process and the trade-offs involved.
Am Mo., 27. Jan. 2020 um 21:12 Uhr schrieb Marshall Dawson < marshalldawson3rd@gmail.com>:
Instead, please give me the opportunity to review any of your changes that touch the picasso directory. If I have any concerns of building, I can test and run it locally, recommend solutions, etc. We can expect a few problems to slip through that process, which I will immediately discover prior to repushing my subsequent work. I will fix it, and allow you to review that work. I am also committed to converting anything resembling a fork to amd/common where it makes sense, and when the development priorities allow. The instant that mb/amd/mandolin lands, it will no longer be work-in-progress and it will undoubtedly build successfully.
Should we add stub mainboards for new chipsets that build the code as a way to make sure nobody else inadvertently breaks things (at least not too bad)? While it's reassuring to know that you intend to keep track of these things and sort them out, that would help other developers do changes with more confidence that they won't leave a huge mess in a hard-to-test area of the tree.
Ironically, I could have commonized the SMBus feature several times over
within the time we’ve had this discussion. I feel this is an important topic, however, so thank you for indulging me. Although I still won’t reprioritize this work ahead of what I promised to my stakeholders, I believe the time discussing this was valuable.
I'm quite sure that you won't forget all the little places that you intend to clean-up down the road. Would it help to document these somewhere, e.g. as issues on ticket.coreboot.org? Both for helping you keep track of things and to state publicly what you've postponed (so you don't have to argue every time somebody else gets the same idea that there's something that could be deduplicated).
Patrick