Hi Tom,
On 1/19/26 5:47 PM, Tom Rini wrote:
On Mon, Jan 19, 2026 at 01:27:52PM +0100, Quentin Schulz wrote:
Hi Tom,
On 1/16/26 7:16 PM, Tom Rini wrote:
As seen with commit d503633a3676 ("Revert "doc: board: starfive: update
jh7110 common description""), it has not always been clear what is and
isn't allowed by custodians, and what the expectations are. To prevent
further unintentional conflicts, document the limited cases where
custodians are allowed to modify patches directly, and how to do that.
Signed-off-by: Tom Rini <[email protected]>
---
Changes in v2:
- New patch.
---
doc/develop/process.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 6f5bdd3db957..775a855fd7a0 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -144,6 +144,12 @@ feedback to the submitter of a patch about what is going
on:
feels it has been too long since posting their patch and not
received any feedback, it is OK to follow-up and ask.
+ * A custodian may make spelling corrections, spacing fixes and other
+ obviously correct trivial changes. They must also in turn amend
I guess people will have a different interpretation as to *what* is an
"obviously correct trivial change", based on the U-Boot git history, are
Yes, but this is intentional, honestly. In my other follow-up to E
Shattow I mentioned there is other general process stuff we need as a
project. Custodians are trusted members of the project and should have
some leeway.
Ack.
there some commits that used the [] + SoB form that are fine or shouldn't
have be made such that we can elaborate a bit more?
Yes, we've made changes before that perhaps really shouldn't have been,
or at least are questionable and should have had more discussion.
I was just suggesting to provide real-life examples in the docs so
people have some idea on how to format the commit log for example. I am
neither intending nor expecting to review all commits ever made to check
if some changes were made without approval from/feedback to the contributor.
I think providing an example would be nice, e.g. the patch as on the mailing
list and after being merged with changes (obviously one you think followed
the rules here). This will make the section longer for sure but it'll be a
visual cue that this is important.
I would suggest to require the custodian to notify as answer to the original
patch if any change was made when merging the patch, even if the changes
match the allowed list of changes listed above. What do you think?
I worry that we're making too many changes in the wrong direction, based
It's always a fine balance to find. I guess this could be less "needed"
if we encourage custodians to use b4 ty to send thank you notes when
merging. Then one can simply go and check the commit themselves (or like
you alluded in the v1, have tooling that can check that).
It's always easy to suggest processes when you won't have to follow them
yourself, so I'm mostly asking questions or suggesting things.
on the problem that did occur. Which was a real problem. But it was also
something that obviously fell outside of the "trivially correct" rule
above, as it was adding new content.
Ack.
Maybe, since the kind of spacing and spelling fixes I perform are the
kind checkpatch complains about, and submitters are already supposed to
use checkpatch, I should reword it to something like:
A custodian may make corrections to patches that checkpatch.pl
(reference) notes, or may request the author re-submit after fixing
them, at their discretion.
This does help but only for code parts. We don't really have anything
for the docs for example, or Kconfig, where typos or formatting errors
can creep in. But I assume you intended to keep the whitespace/typo as
general rules and just add the checkpatch requirement for everything
that falls out of those rules?
We can always improve this over time, better have something explained
now and refined later if custodians have questions or feedback to provide.
Cheers,
Quentin
