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 > <20200423100837.jllsb57rjitmd...@tomti.i.net-space.pl>. > > 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 > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel