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, areYes, 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. > 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 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 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. 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. -- Tom
signature.asc
Description: PGP signature
