Not much to add to mmeeks mail regarding the commit messages rewrites. Am 14.11.18 um 13:15 schrieb Michael Meeks: > On 14/11/2018 11:57, Gülşah Köse wrote: >> I'd like to ask you about a topic. When Mert closed some bugs about >> Android that were sponsored by Pardus, I noticed that the commit message >> was wrong (They want [Pardus] is to be written in commit message) and >> the patch was merged.
I guess you're talking about the first line of the commit message, which is interpreted by various tools as a summary. > I suspect that we should prolly get a formalized flow to credit commits > to a given entity when they're submitted by someone else - and hack that > into our gitdm tooling at some stage - so using some (future) > machine-readable format would be a good example there; eg. [Pardus]. We already have this as a commit message footer, like Change-Id, Reviewed-on, Tested-by, etc. Everybody can easily add a "Sponsored-by" "field". No problem to parse this with any tooling I guess, if we go with a simple "<key>: <value>". We can suggest some default keys, which are used by our tooling. The Linux kernel mentions some in their Documentation/process/submitting-patches.rst. Just please don't start putting more stuff in the first commit line, which doesn't describe technical functionality of the patch. I would actually move the "tdf#..." to a "Fixes: tdf#12345" and also allow multiple of these entries. Maybe also a "Regression-from: <commit id>", so it's easier to catch multiple patches when backporting fixes. As this is managed by humans, it won't be perfect but better then nothing. Formats like the one used by debian/control even allow multiple lines per key by indention, but we should be fine without, as the rest of the commit message is free text. Jan-Marek _______________________________________________ LibreOffice mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice
