Re: How to submit patches and patchsets via grub-devel

[Daniel Axtens]

Hi Hans,

> Hello,
>
> as I am continuing to flood this mailing list with patches, I am
> realizing that I am missing some general rules for how things work on
> grub-devel. Sorry for the inconvenience caused by that.
>
> Anyway, here are a few questions I am beginning realize I should know
> the answers to before posting patches to grub-devel:
>
>   * What to put into the cover letter (git send-email --compose)?
>
>   * How to format commit messages?
>
>   * What about those special lines within commit messages?
>
>       * Signed-off-by:
>       * Reviewed-by:
>
>     Who adds these special lines and when? If Daniel replies to me
>     posting a patch with "Reviewed-by: Daniel", does that mean I should
>     include that in my next iteration of that patch? Does it mean
>     Daniel approves of the patch and plans to merge it to master
>     himself with or without adding the Reviewed-by by himself?
>
>     Are there other special lines I need to be aware of?

I don't know about grub specifically but these lines are extremely
common in the linux kernel community, where they're documented at:
(picking v4.17 as it came up first in the google search results and it's
still pretty current)

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html

Specifically:

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes

I generally follow the kernel patch guidelines across any project I
contribute to where appropriate - obviously in this case there are
things like the GNU coding style rather than the linux coding style, so
it's not all applicable! But I think the kernel guidance on patch format
is extremely good and generally applicable - that might answer your
first two questions.

>
>   * How are reviews done? Is there a formal definition of preconditions
>     which must be satisfied before something is actually committed to
>     the master branch?

Again, just in terms of kernel practice, see
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes

Projects (and indeed different subsystems within the kernel) have
different rules about what's formally required (e.g. is a Reviewed-by
required, does the maintainer apply a reviewed-by tag or a signed-off-by
tag) so I won't speak for Daniel K on this.

> I presume a good place to write those down for grub would be
> docs/grub-dev.texi. I had not intended to touch grub-dev.texi much
> before 2.06, but apparently this needs to be done first so I can
> properly do the other things for 2.06. Am I wrong in this presumption
> and just missing the place where the general rules on how to contribute
> patches are written down?
>
> Anyway, when I am finding out what those rules are I can start
> writing them down without much additional effort, starting with what
> Daniel replied to me in
> <address@hidden>.
>
> Please add to this list if you notice something missing from it, so I
> can collect all that, write it up for docs/grub-dev.texi and post a
> patch updating docs/grub-dev.texi in a week or two.
>
> So, here are the "how to submit patches via grub-devel" rules so far:
>
>   * If you post more than one patch, create a cover email
>     (git send-email --compose ...).

I tend to use git format-patch --cover-letter and then look over
everything first - but most of my colleagues do it the way you've
suggested.
>
>   * Create a new email thread for a new patchset. Do not attach it
>     to existing email threads.
>
>   * If you need to repost a patchset, repost the whole series of
>     patches as a new email thread instead of just reposting some
>     individual patches.
>

My personal opinion is that these are all excellent rules for all
involved.

Regards,
Daniel


> Thanks for your help.
>
> Uli
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel