On 30 October 2026 16:03:35 GMT, Quentin Schulz <[email protected]> wrote: >Hi Bradley, > >On 10/30/26 3:40 PM, Bradley Morgan wrote: >> On 30 October 2026 14:24:36 GMT, Tom Rini <[email protected]> wrote: >>> On Fri, Oct 30, 2026 at 02:14:08AM +0000, Bradley Morgan wrote: >>>> On Fri, 30 Oct 2026 02:08:27 +0000, Bradley Morgan wrote: >>>>> There is almost nothing in doc/arch/ for powerpc, so this adds a >>> folder >>>>> like the x86 one, with four pages: >>>>> >>>>> - an overview: what the port is, the cpu families, the boards, how to >>>>> build it, the config options people ask about >>>>> >>>>> - the mpc85xx boot images: the NOR, RAMBOOT and NAND layouts, and the >>>>> CONFIG_SYS_MPC85XX_NO_RESETVEC and SPL/TPL knobs >>>>> >>>>> [...] >>>> >>>> Applied to next at u-boot-ppc, Thanks! >>>> >>>> [1/4] doc: arch/powerpc: add an overview >>>> >>> >https://git.u-boot-project.org/u-boot/custodians/u-boot-ppc/-/commit/e6a37f4dfeea >>>> [2/4] doc: arch/powerpc: document the mpc85xx boot images >>>> >>> >https://git.u-boot-project.org/u-boot/custodians/u-boot-ppc/-/commit/3287ff140823 >>>> [3/4] doc: arch/powerpc: add a PBL guide >>>> >>> >https://git.u-boot-project.org/u-boot/custodians/u-boot-ppc/-/commit/b74d2c1efaac >>>> [4/4] doc: arch/powerpc: add a booting and porting guide >>>> >>> >https://git.u-boot-project.org/u-boot/custodians/u-boot-ppc/-/commit/0851db824add >>> >>> For non-critical changes, please wait at least a few days. I'm hoping >>> that for the documentation stuff you're doing that Heinrich will have a >>> chance to look at them, for example. >> >> Hi, don't panic, I'll drop them if there is issues. >> > >I do not review patches that were already merged, so you guarantee >yourself at least one fewer pair of eyes on your patches. Dropping commits >you've said you've merged should really be last resort, and should be >explicitly and publicly communicated, with changes made to their state in >patchwork as well, otherwise we are going to lose patches and people think >some patches they found on the mailing list were merged.
Understood. > >There is almost nothing that requires merging that fast, *especially >without reviews*. And if something requires merging that fast, a lot of >eyes should be on it. We've had a case like that a few months ago with the >critical vulnerability for FIT image verification for example and we still >didn't merge that fast. Ack. > >Merging without reviews could be seen as a way to introduce >vulnerabilities in the project. The contributor rules still apply when >sending patches even if you are a custodian. There's some grey area when >you're contributing to some area where nobody reviews or maintains, but >usually Tom eventually gets to those I believe. PPC is one of those grey >areas because there are so few contributors and until now no active >custodian as far as I understood, so I'm not sure what we are expecting as >a workflow here to be honest. We'll figure something out on the way I >guess. Yeah, no reviewers sadly. So in in a hole on the ground here, hmm, maybe another guy could be reviewer too, 1 M one R entry. > >You also sent a v1 at 1:49pm UTC today, then a v2 about an hour later, and >merged a few minutes after. Please wait a few days between versions so >people can review the latest version and the ML doesn't get spammed. If >you found issues in your v1 and don't want people to waste time on some >parts you're going to modify anyway in a v2, you can answer to your own >mail and specify what you're going to replace (i.e. doing a review of your >own code). I did a Self-NAK. > >> Also, remind me, is Heinrich the Hitachi guy? I don't remember. >> > >$ grep Heinrich MAINTAINERS >M: Heinrich Schuchardt <[email protected]> >M: Heinrich Schuchardt <[email protected]> >R: Heinrich Schuchardt <[email protected]> AHH. Makes sense, cheers > >Cheers, >Quentin > --- Thanks!
