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

Reply via email to