On Mon, Jan 27, 2020 at 3:57 PM Patrick Georgi via coreboot < coreboot@coreboot.org> wrote:
> 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 < > marshalldawson...@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. > having a src/mainboard/stub/<soc> for **all** SoC might not be a bad idea, especially if it were to select less common/non-default options that other in-tree boards don't select by default, to ensure full coverage of all SoC options. > > 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). > for a WIP SoC, seems like comments in the code/header files indicating WIP status or need to revisit would be a consistent, visible reminder that the code isn't "finalized" > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org >
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org