On Mon, Jan 19, 2026 at 07:02:50PM +0100, Quentin Schulz wrote:
> 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.OK, thanks. > > > 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). I think more custodians using b4 would help (as discussed slightly on irc, it offers good patchwork integration too), but thats not exactly what E Shattow was suggesting for a tooling idea, I believe. But I do believe more custodians using "b4 ty" would be helpful as it provides "is applied" along with "this commit hash". > 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. Yes, thanks. :) > > 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. Note that checkpatch.pl will (modulo bugs) catch spelling problems globally. We now have it catching (some) spacing issues in Kconfig files, but since the kernel doesn't enforce something there it's local to us. -- Tom
signature.asc
Description: PGP signature
