Hi,
On 01.11.26 08:22, Heiko Schocher wrote:
Hi Quentin,
On 30.10.26 17:03, Quentin Schulz 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.
+1
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.
+1 !
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.
+1
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).
Thats a no go from my side!
You can't send your patches after you've already sent them an hour ago.
Sorry, typo. I meant: You can't merge your own patches that fast.
bye,
Heiko
No human can review your patches within an hour!
Give people time!
Most of them are not paid for this!
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]>
Cheers,
Quentin
bye,
Heiko
--
Nabla Software Engineering
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: [email protected]
Geschäftsführer : Stefano Babic
