Talk:Gentoo git workflow
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 16:32, 21 November 2024 (UTC) :: Your reply ~~~~
Referencing bug reports
Various suggestions have been made on gentoo-dev on how to include bug report refernces in commit messages. For now, there is no consensus on the format. Should all be listed here? Chithanh (talk) 01:25, 12 August 2015 (UTC)
I have summed up the results and they look like
reference the bug only in the summary: 1 don't make any of this mandatory: 1 "Gentoo-Bug: 123" or similar short form: 9 "Gentoo-Bug: <url>" or similar long form: 2-3
That, to me, suggests that we should do the following:
- make "Gentoo-Bug: 123" mandatory (for multiple bugs, separate with
,, if that exceeds the max line length, start a new "Gentoo-Bug:" line for the rest of the items) - leave it to the committer if he wants to add the bug number in the summary
- leave it to the committer if he wants to add "Gentoo-Bug-url: <url>" to the commit message description
Hasufell (talk) 11:16, 12 August 2015 (UTC)
Sping (talk): My understanding was that "(bug #123456)" was the way we have always been referencing Gentoo bugs. Fot upstream bugs, "(upstream bug #12345)" or "(gnome bug #12345)" makes sense and was used as well, I believe. That would avaid the unecessary length of "Gentoo-Bug:" with Gentoo being the by far more common case, to my impression.
Chithanh (talk) 13:09, 24 August 2015 (UTC) : As still no consensus is reached I propose to add the following to the article below Gentoo git workflow#commit message format which should cover most suggestions:
Referencing bug reports
There is no policy or consensus on how to best reference bug reports in commit messages. The following are examples of what has been suggested and/or is in use currently:
- "bug 333531" or "bug #333531" in the first line of the commit message
- in the third or later line:
- Gentoo-Bug: 333531
- Bug: 333531
- Bug: https://bugs.gentoo.org/333531
- Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531
If you are referencing external bug trackers instead of Gentoo Bugzilla, it is a good idea to give the full URL.
Chithanh (talk) 13:09, 24 August 2015 (UTC)
Sign-Off
repoman currently does not add Signed-Off-By. Do we want this? When using git to commit, it was suggested to use both -S and -s. Chithanh (talk) 01:25, 12 August 2015 (UTC)
IMO, it is fairly useless to us. It is used by the kernel, because they toss patches around wildly through different committers/authors and have to know where that thing originates and who was working on it.
The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path.
We mainly try to keep committer == author (e.g. we don't cherry-pick user patches, but merge them with an enforced merge commit. And even if someone else commits, there's usually just one author), so it isn't very useful to us, because we don't have such an indirect and complicated workflow.
However, Acked-by:, Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: sound useful to me.
Hasufell (talk) 11:00, 12 August 2015 (UTC)
Repoman adds Signed-off-by: when DCO_SIGNED_OFF_BY is set (see man make.conf). Or does it not work any more with git?
In 2013 there was a discussion on the nfp list about making DCOs a mandatory part of our Copyright and Attribution Policy. I'm unsure what the outcome of that discussion was, but DCO_SIGNED_OFF_BY was added to portage a couple months later, which suggests we were leaning in that direction. Maybe get in touch with the trustees to see what the status of this is.
https://archives.gentoo.org/gentoo-nfp/message/688f56f2f5828f5da0049d45d91d822c
https://archives.gentoo.org/gentoo-dev/message/2c2feba457e81ca25ea8871ab72347b3
--RyanHill (talk) 06:23, 13 August 2015 (UTC)
DCO_SIGNED_OFF_BY in make.conf still works with git and is useful for me, now that commits to user repositories must be signed.
AstroFloyd (talk) 10:50, 19 November 2018 (UTC)
PORTAGE_GPG_KEY vs. user.signingkey exclamation mark
When using a dedicated signing subkey, PORTAGE_GPG_KEY is suggested to contain a ! at the end. Under which circumstances should this apply to user.signingkey too? Chithanh (talk) 01:25, 12 August 2015 (UTC)
- I was informed by K_F on IRC that the same rules apply for both user.signingkey and PORTAGE_GPG_KEY regarding whether to put a ! or not. Chithanh (talk) 13:11, 24 August 2015 (UTC)
git config
We instruct the developers to push signed. Why not add that to the local repository's config?
user $git config --local push.gpgSign 1--Nicolas Bock (talk) 13:16, 19 April 2016 (UTC)