[PATCH 0/3] Documenting commit reverts and revocation

DoneSubmitted by Ludovic Courtès.
Details
7 participants
  • Julien Lepiller
  • Leo Famulari
  • Ludovic Courtès
  • Christopher Baines
  • Maxime Devos
  • Tobias Geerinckx-Rice
  • Xinglu Chen
Owner
unassigned
Severity
normal
L
L
Ludovic Courtès wrote on 27 May 14:32 +0200
(address . guix-patches@gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
20210527123259.4115-1-ludo@gnu.org
Hello Guix!
Attached is an attempt to:
1. Structure the “Commit Access” section of the manual;
2. Document how to address committers’ mistakes, when to revert commits;
3. Explain under what circumstances maintainers may revoke commit rights.
It essentially codifies unwritten rules, but as always, I think it’sbetter to be explicit about the rules and community expectations.
Let me know what you think! I propose to leave a comment periodof at least one week, possibly iterating with new versions.
Ludo’.
Ludovic Courtès (3): doc: Structure the "Commit Access" section. doc: Add "Addressing Mistakes" section. doc: Explain more reasons for commit revocation.
doc/contributing.texi | 114 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 93 insertions(+), 21 deletions(-)
-- 2.31.1
L
L
Ludovic Courtès wrote on 27 May 14:35 +0200
[PATCH 1/3] doc: Structure the "Commit Access" section.
(address . 48696@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
20210527123554.4267-1-ludo@gnu.org
* doc/contributing.texi (Commit Access): Add introduction and sectionheading. Separate OpenPGP setup from commit policy.--- doc/contributing.texi | 59 ++++++++++++++++++++++++++++--------------- 1 file changed, 38 insertions(+), 21 deletions(-)
Toggle diff (99 lines)diff --git a/doc/contributing.texi b/doc/contributing.texiindex cfcae22502..7dc912b4de 100644--- a/doc/contributing.texi+++ b/doc/contributing.texi@@ -1258,8 +1258,19 @@ this nifty tool! @section Commit Access @cindex commit access, for developers-For frequent contributors, having write access to the repository is-convenient. When you deem it necessary, consider applying for commit+Everyone can contribute to Guix without having commit access+(@pxref{Submitting Patches}). However, for frequent contributors,+having write access to the repository can be convenient. Commit access+should not be thought of as a ``badge of honor'' but rather as a+responsibility a contributor is willing to take to help the project.++The following sections explain how to get commit access, how to be ready+to push commits, and the policies and community expectations for commits+pushed upstream.++@subsection Applying for Commit Access++When you deem it necessary, consider applying for commit access by following these steps: @enumerate@@ -1331,6 +1342,27 @@ review and merging system, which, as a consequence, may lead us to have fewer people with commit access to the main repository. Stay tuned! @end quotation +All commits that are pushed to the central repository on Savannah must+be signed with an OpenPGP key, and the public key should be uploaded to+your user account on Savannah and to public key servers, such as+@code{keys.openpgp.org}. To configure Git to automatically sign+commits, run:++@example+git config commit.gpgsign true+git config user.signingkey CABBA6EA1DC0FF33+@end example++You can prevent yourself from accidentally pushing unsigned commits to+Savannah by using the pre-push Git hook called located at+@file{etc/git/pre-push}:++@example+cp etc/git/pre-push .git/hooks/pre-push+@end example++@subsection Commit Policy+ If you get commit access, please make sure to follow the policy below (discussions of the policy can take place on @email{guix-devel@@gnu.org}).@@ -1349,25 +1381,6 @@ mailing list for commit notifications (@email{guix-commits@@gnu.org}), so people can notice. Before pushing your changes, make sure to run @code{git pull --rebase}. -All commits that are pushed to the central repository on Savannah must-be signed with an OpenPGP key, and the public key should be uploaded to-your user account on Savannah and to public key servers, such as-@code{keys.openpgp.org}. To configure Git to automatically sign-commits, run:--@example-git config commit.gpgsign true-git config user.signingkey CABBA6EA1DC0FF33-@end example--You can prevent yourself from accidentally pushing unsigned commits to-Savannah by using the pre-push Git hook called located at-@file{etc/git/pre-push}:--@example-cp etc/git/pre-push .git/hooks/pre-push-@end example- When pushing a commit on behalf of somebody else, please add a @code{Signed-off-by} line at the end of the commit log message---e.g., with @command{git am --signoff}. This improves tracking of who did@@ -1389,12 +1402,16 @@ you're confident, it's OK to commit. That last part is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with. +@subsection Commit Revocation+ In order to reduce the possibility of mistakes, committers will have their Savannah account removed from the Guix Savannah project and their key removed from @file{.guix-authorizations} after 12 months of inactivity; they can ask to regain commit access by emailing the maintainers, without going through the vouching process. +@subsection Helping Out+ One last thing: the project keeps moving forward because committers not only push their own awesome changes, but also offer some of their time @emph{reviewing} and pushing other people's changes. As a committer,-- 2.31.1
L
L
Ludovic Courtès wrote on 27 May 14:35 +0200
[PATCH 2/3] doc: Add "Addressing Mistakes" section.
(address . 48696@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
20210527123554.4267-2-ludo@gnu.org
* doc/contributing.texi (Addressing Mistakes): New section.--- doc/contributing.texi | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+)
Toggle diff (47 lines)diff --git a/doc/contributing.texi b/doc/contributing.texiindex 7dc912b4de..8308551261 100644--- a/doc/contributing.texi+++ b/doc/contributing.texi@@ -1402,6 +1402,40 @@ you're confident, it's OK to commit. That last part is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with. +@subsection Addressing Mistakes++We all make mistakes. We expect peer review (@pxref{Submitting+Patches}) and tools such as @command{guix lint} (@pxref{Invoking guix+lint}) and the test suite (@pxref{Running the Test Suite}) to catch+issues before they are pushed; yet, mistakes might go through---that+happens to both newcomers and old-timers, and there is nothing to be+ashamed of when it happens. As a community, we expect committers to+recognize and address mistakes as soon as possible.++Some mistakes can directly affect all users---for instance because they+make @command{guix pull} fail or break core functionality, because they+break major packages (at build time or run time), or because they+introduce known security vulnerabilities.++@cindex reverting commits+The person who pushed the faulty commit(s) should be at the forefront to+address such an issue in a timely fashion: by pushing a followup commit+to fix it (if possible), or by reverting it to leave time to come up+with a proper fix, and by communicating with other developers about the+problem.++If the committer is unavailable to address the issue in time, other+committers are entitled to revert the offending commit(s), explaining in+the commit log and on the mailing list what the problem was, with the+goal of leaving time to the original committer and author(s) to propose+a way forward.++The Guix project values friendly cooperation and a constant effort to+focus on the way forward when issues arise. Committers should lead by+example, notably as a way to encourage contributors and contributors to+be. Blame as well as defensiveness do not have their place in Guix when+addressing genuine mistakes.+ @subsection Commit Revocation In order to reduce the possibility of mistakes, committers will have-- 2.31.1
L
L
Ludovic Courtès wrote on 27 May 14:35 +0200
[PATCH 3/3] doc: Explain more reasons for commit revocation.
(address . 48696@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
20210527123554.4267-3-ludo@gnu.org
* doc/contributing.texi (Commit Revocation): Expound.--- doc/contributing.texi | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
Toggle diff (34 lines)diff --git a/doc/contributing.texi b/doc/contributing.texiindex 8308551261..ec649c8e13 100644--- a/doc/contributing.texi+++ b/doc/contributing.texi@@ -1444,6 +1444,27 @@ key removed from @file{.guix-authorizations} after 12 months of inactivity; they can ask to regain commit access by emailing the maintainers, without going through the vouching process. +Maintainers@footnote{See @uref{https://guix.gnu.org/en/about} for the+current list of maintainers. You can email them privately at+@email{guix-maintainers@@gnu.org}.} may also revoke an individual's+commit rights, as a last resort, if cooperation with the rest of the+community has caused too much friction---even within the bounds of the+project's code of conduct (@pxref{Contributing}). They would only do so+after public or private discussion with the individual and a clear+notice. Examples of behavior that hinders cooperation and could lead to+such a decision include:++@itemize+@item repeated violation of the commit policy stated above;+@item repeated failure to take peer criticism into account;+@item breaching trust through a series of grave incidents.+@end itemize++When maintainers resort to such a decision, they notify developers on+@email{guix-devel@@gnu.org}; inquiries may be sent to+@email{guix-maintainers@@gnu.org}. Depending on the situation, the+individual may still be welcome to contribute.+ @subsection Helping Out One last thing: the project keeps moving forward because committers not-- 2.31.1
J
J
Julien Lepiller wrote on 27 May 15:55 +0200
Re: [bug#48696] [PATCH 1/3] doc: Structure the "Commit Access" section.
8FB0AFE9-B53B-42F7-8635-D6B4DA763FC3@lepiller.eu
Le 27 mai 2021 08:35:52 GMT-04:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
Toggle quote (56 lines)>* doc/contributing.texi (Commit Access): Add introduction and section>heading. Separate OpenPGP setup from commit policy.>---> doc/contributing.texi | 59 ++++++++++++++++++++++++++++---------------> 1 file changed, 38 insertions(+), 21 deletions(-)>>diff --git a/doc/contributing.texi b/doc/contributing.texi>index cfcae22502..7dc912b4de 100644>--- a/doc/contributing.texi>+++ b/doc/contributing.texi>@@ -1258,8 +1258,19 @@ this nifty tool!> @section Commit Access> > @cindex commit access, for developers>-For frequent contributors, having write access to the repository is>-convenient. When you deem it necessary, consider applying for commit>+Everyone can contribute to Guix without having commit access>+(@pxref{Submitting Patches}). However, for frequent contributors,>+having write access to the repository can be convenient. Commit>access>+should not be thought of as a ``badge of honor'' but rather as a>+responsibility a contributor is willing to take to help the project.>+>+The following sections explain how to get commit access, how to be>ready>+to push commits, and the policies and community expectations for>commits>+pushed upstream.>+>+@subsection Applying for Commit Access>+>+When you deem it necessary, consider applying for commit> access by following these steps:> > @enumerate>@@ -1331,6 +1342,27 @@ review and merging system, which, as a>consequence, may lead us to have> fewer people with commit access to the main repository. Stay tuned!> @end quotation> >+All commits that are pushed to the central repository on Savannah must>+be signed with an OpenPGP key, and the public key should be uploaded>to>+your user account on Savannah and to public key servers, such as>+@code{keys.openpgp.org}. To configure Git to automatically sign>+commits, run:>+>+@example>+git config commit.gpgsign true>+git config user.signingkey CABBA6EA1DC0FF33>+@end example>+>+You can prevent yourself from accidentally pushing unsigned commits to>+Savannah by using the pre-push Git hook called located at>+@file{etc/git/pre-push}:
This sentence sounds weird. Isn't "called" superfluous?
Toggle quote (56 lines)>+>+@example>+cp etc/git/pre-push .git/hooks/pre-push>+@end example>+>+@subsection Commit Policy>+> If you get commit access, please make sure to follow> the policy below (discussions of the policy can take place on> @email{guix-devel@@gnu.org}).>@@ -1349,25 +1381,6 @@ mailing list for commit notifications>(@email{guix-commits@@gnu.org}),> so people can notice. Before pushing your changes, make sure to run> @code{git pull --rebase}.> >-All commits that are pushed to the central repository on Savannah must>-be signed with an OpenPGP key, and the public key should be uploaded>to>-your user account on Savannah and to public key servers, such as>-@code{keys.openpgp.org}. To configure Git to automatically sign>-commits, run:>->-@example>-git config commit.gpgsign true>-git config user.signingkey CABBA6EA1DC0FF33>-@end example>->-You can prevent yourself from accidentally pushing unsigned commits to>-Savannah by using the pre-push Git hook called located at>-@file{etc/git/pre-push}:>->-@example>-cp etc/git/pre-push .git/hooks/pre-push>-@end example>-> When pushing a commit on behalf of somebody else, please add a> @code{Signed-off-by} line at the end of the commit log message---e.g.,> with @command{git am --signoff}. This improves tracking of who did>@@ -1389,12 +1402,16 @@ you're confident, it's OK to commit.>That last part is subject to being adjusted, allowing individuals to>commit> directly on non-controversial changes on parts they’re familiar with.> >+@subsection Commit Revocation>+> In order to reduce the possibility of mistakes, committers will have>their Savannah account removed from the Guix Savannah project and their> key removed from @file{.guix-authorizations} after 12 months of> inactivity; they can ask to regain commit access by emailing the> maintainers, without going through the vouching process.> >+@subsection Helping Out>+>One last thing: the project keeps moving forward because committers not> only push their own awesome changes, but also offer some of their time> @emph{reviewing} and pushing other people's changes. As a committer,
L
L
Leo Famulari wrote on 27 May 16:16 +0200
Re: [bug#48696] [PATCH 0/3] Documenting commit reverts and revocation
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48696@debbugs.gnu.org)
YK+pvNseB4Oc05Qc@jasmine.lan
On Thu, May 27, 2021 at 02:32:59PM +0200, Ludovic Courtès wrote:
Toggle quote (18 lines)> Hello Guix!> > Attached is an attempt to:> > 1. Structure the “Commit Access” section of the manual;> > 2. Document how to address committers’ mistakes, when to revert> commits;> > 3. Explain under what circumstances maintainers may revoke commit> rights.> > It essentially codifies unwritten rules, but as always, I think it’s> better to be explicit about the rules and community expectations.> > Let me know what you think! I propose to leave a comment period> of at least one week, possibly iterating with new versions.
Thanks for putting this together. It looks good to me!
M
M
Maxime Devos wrote on 27 May 21:10 +0200
Re: [bug#48696] [PATCH 1/3] doc: Structure the "Commit Access" section.
53c9218bbf5b72e0b159014e424aeb8782d4d457.camel@telenet.be
Ludovic Courtès schreef op do 27-05-2021 om 14:35 [+0200]:
Toggle quote (11 lines)> +All commits that are pushed to the central repository on Savannah must> +be signed with an OpenPGP key, and the public key should be uploaded to> +your user account on Savannah and to public key servers, such as> +@code{keys.openpgp.org}. To configure Git to automatically sign> +commits, run:> +> +@example> +git config commit.gpgsign true> +git config user.signingkey CABBA6EA1DC0FF33> +@end example
Is that meant to represent ‘cabbage and coffee’ in l33t?Maybe replace this with something like
+@example
Toggle quote (5 lines)> +git config commit.gpgsign true> +# Substitute the fingerprint of your public PGP key> +git config user.signingkey CABBA6EA1DC0FF33> +@end example
Basic, I know, but people have to learn the basics fromsomewhere, so maybe best be explicit here.
Toggle quote (2 lines)> + [... some newlines after @section{...} ]
These extra newlines could go directly into 'master' I guess.The rest of [PATCH 1/3] seems ok to me?
Greetings,Maxime.
-----BEGIN PGP SIGNATURE-----
iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYK/ujRccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7jmZAQD7TBUVWashoIa/4RIpvybic5d5ijDr/rwVbqww95XoCgD+KNwzET8g3Dw9rsMSmO+g5wS3mmvf0KVNSdPPYQlOTwM==FryL-----END PGP SIGNATURE-----

M
M
Maxime Devos wrote on 27 May 21:13 +0200
Re: [bug#48696] [PATCH 3/3] doc: Explain more reasons for commit revocation.
1e92fa266926fc0bba560f9775727e518f8f9a9e.camel@telenet.be
PATCH 2/3 and PATCH 3/3 also seem good to me.
Greetings,Maxime.
-----BEGIN PGP SIGNATURE-----
iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYK/vSBccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7ggfAP9eO0a/rRsugyGa2W7KVI7VTrOtnjXQUh5O6bD4jlf2xwD/bdy/h2XHO/CB01P6j03dZjS0Y/aRFmloRJCYPqTT5QM==MDbW-----END PGP SIGNATURE-----

C
C
Christopher Baines wrote on 27 May 21:19 +0200
Re: [bug#48696] [PATCH 2/3] doc: Add "Addressing Mistakes" section.
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48696@debbugs.gnu.org)
87y2c0f0i4.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (47 lines)> * doc/contributing.texi (Addressing Mistakes): New section.> ---> doc/contributing.texi | 34 ++++++++++++++++++++++++++++++++++> 1 file changed, 34 insertions(+)>> diff --git a/doc/contributing.texi b/doc/contributing.texi> index 7dc912b4de..8308551261 100644> --- a/doc/contributing.texi> +++ b/doc/contributing.texi> @@ -1402,6 +1402,40 @@ you're confident, it's OK to commit.> That last part is subject to being adjusted, allowing individuals to commit> directly on non-controversial changes on parts they’re familiar with.> > +@subsection Addressing Mistakes> +> +We all make mistakes. We expect peer review (@pxref{Submitting> +Patches}) and tools such as @command{guix lint} (@pxref{Invoking guix> +lint}) and the test suite (@pxref{Running the Test Suite}) to catch> +issues before they are pushed; yet, mistakes might go through---that> +happens to both newcomers and old-timers, and there is nothing to be> +ashamed of when it happens. As a community, we expect committers to> +recognize and address mistakes as soon as possible.> +> +Some mistakes can directly affect all users---for instance because they> +make @command{guix pull} fail or break core functionality, because they> +break major packages (at build time or run time), or because they> +introduce known security vulnerabilities.> +> +@cindex reverting commits> +The person who pushed the faulty commit(s) should be at the forefront to> +address such an issue in a timely fashion: by pushing a followup commit> +to fix it (if possible), or by reverting it to leave time to come up> +with a proper fix, and by communicating with other developers about the> +problem.> +> +If the committer is unavailable to address the issue in time, other> +committers are entitled to revert the offending commit(s), explaining in> +the commit log and on the mailing list what the problem was, with the> +goal of leaving time to the original committer and author(s) to propose> +a way forward.> +> +The Guix project values friendly cooperation and a constant effort to> +focus on the way forward when issues arise. Committers should lead by> +example, notably as a way to encourage contributors and contributors to> +be. Blame as well as defensiveness do not have their place in Guix when> +addressing genuine mistakes.
I too would like to see less blame, but one factor is how things areframed and the language used.
On the language here, "mistake" is a word I would generally avoid if theaim is avoid blaming someone, since mistakes are made by a person or setof people. I'd prefer a term like "problem", since I don't perceievethat as directly linked to a person or set of people.
On the bit about the "person who pushed the faulty commits" (so, personto blame...) I'd much prefer an emphisis on group responsibility tomitigate the impact of problems quickly, and understand the factors thatled to that problems in the first place. That avoids assigning blame,rather than the process pushing responsibility to the person to blame("person who pushed the faulty commit(s)").
On this same thread, I'd like to see less blaming in the form of askingpeople to "explain". When there's a problem, and you ask someone toexplain, I would interpret that as "I'm blaming you for this, pleasegive your account of how the mistake was made", to which the person caneither answer explaining the details as to why they are to blame, or candisagree with the implicit assertion that they are to blame. To avoidassigning blame, one can just ask someone to "describe" what happened,which I wouldn't interpret as being loaded with the same implicitassertion.
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmCv8LNfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9Xc48A//YgEpbNOW8DOT17E3DEYQm2u4ci+ChAB/rmQ9fROQ7UYeB5Kki7TTKrPy25F8Gd+wimkwNvBEHp12drxemTlzKGyXK8nIBLwzruW0kb9+FnNtloVsMYKfpZ1wNM6UIaTqv+kOUm0Y24oXuMS+5J4pQNtoqsK0EHswqNybzVCHhOgPMFJpbmcTP0Kl2aGY3P4FUo3HeBZUbGiyvezoUvIPVZvyJFwBnn9Wk2BDIm/yDrEY1xJmvZs7LcSL+SOr3yXF59koF3PbUmy6dOfQCJvkPizIBQOd7iET90Bxy7tU60kXQ5ZRvUJVxV17NT143zdRp4RHj3WFkDbQ09WqLKwSyODQyATFXSFYERwvWSnntjtdy4unOBGLmR3Dz6WcaA6IC31HyxPRHxgT9b8R9hG4oTzJP5MsNvBcoqsYb01V7xoumFz/yXw4avsiEL91mfORpfrkxseIAO5zg1BakkfFtKrj7WmmZzjm5bJ6DEr+4WAePzoOCTcyC9iJz9bcsuTw+3buvYTbmp5I4yJa/9HRkUAAELVrBqky/eTPGnLXLVDj4lP/WrYY/xjvojeUEJiA3UL4dQRX0D5WaLUd2p9m7PPs9b+JVt0tGwoluc409QRp+XvVISw+EDJvnlWA9aUy/cT3jls+ltHnYFd6K43Fkq1ALVuYkl3qmA3obbgRte0==RVx2-----END PGP SIGNATURE-----
C
C
Christopher Baines wrote on 27 May 22:07 +0200
Re: [bug#48696] [PATCH 3/3] doc: Explain more reasons for commit revocation.
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48696@debbugs.gnu.org)
87v974ey8y.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (38 lines)> * doc/contributing.texi (Commit Revocation): Expound.> ---> doc/contributing.texi | 21 +++++++++++++++++++++> 1 file changed, 21 insertions(+)>> diff --git a/doc/contributing.texi b/doc/contributing.texi> index 8308551261..ec649c8e13 100644> --- a/doc/contributing.texi> +++ b/doc/contributing.texi> @@ -1444,6 +1444,27 @@ key removed from @file{.guix-authorizations} after 12 months of> inactivity; they can ask to regain commit access by emailing the> maintainers, without going through the vouching process.>> +Maintainers@footnote{See @uref{https://guix.gnu.org/en/about} for the> +current list of maintainers. You can email them privately at> +@email{guix-maintainers@@gnu.org}.} may also revoke an individual's> +commit rights, as a last resort, if cooperation with the rest of the> +community has caused too much friction---even within the bounds of the> +project's code of conduct (@pxref{Contributing}). They would only do so> +after public or private discussion with the individual and a clear> +notice. Examples of behavior that hinders cooperation and could lead to> +such a decision include:> +> +@itemize> +@item repeated violation of the commit policy stated above;> +@item repeated failure to take peer criticism into account;> +@item breaching trust through a series of grave incidents.> +@end itemize> +> +When maintainers resort to such a decision, they notify developers on> +@email{guix-devel@@gnu.org}; inquiries may be sent to> +@email{guix-maintainers@@gnu.org}. Depending on the situation, the> +individual may still be welcome to contribute.> +> @subsection Helping Out>> One last thing: the project keeps moving forward because committers not
Since the project code of conduct sets out behavioural standards,including mandating "Gracefully accepting constructive criticism" and"Showing empathy towards other community members", I think that combinedwith "following the relevant processes" already covers what you'resetting out here?
I was shocked by [1], which from memory is the first time a technicalmeasure has been used to push a contributor away from the project (atleast that's my interpretation of the effect/intent). I think the futureuse of revoking individuals commit access would be good to discuss.
1: https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00489.html
In abstract, in my opinion, I can only think of three scenarios forremoving someones commit access when they're actively using it:
- Clear violation of the code of conduct
I don't think it's helpful to set out stuff about conduct in other places, particularly bits about unacceptable conduct. If the code of conduct is wrong or not sufficient, it should be revised.
- Suspected malicious intent
Like they didn't just introduce some reference to some dodgy release tarball for a package, but it seems like this could have been done intentionally.
- Process problem for giving out commit access
There's a process and people involved, so it's fair to say that problems can occur. Obviously it's not ideal, but if the process wasn't followed correctly, or if it's been updated and in hindsight different decisions would have been made, I think that's reason enough to apologise, and remove someones commit access.
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmCv/B1fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9XfADg//ZyDdxgEMFtb4gPwTBg+poPMs9UtPffHDUjvUxLE/tFAVc2XmNbb+y39pvRzoKIvv+LSNyKp+cYHP+7cmZYic4skrrKqqyWG5vVlxqrLoH5W3WLAofP/mU3WlSuoN3auCzFZbJ4nmL38YL3kzv0T4lHeT2hGH7+fK+6GeZ6GKZposh4UpABb2M3Q6FRnnIqRlIxHgnG9hg3SKtNF4zPobTeVbxepu5qsxvXXTeF2XHVTL/P3LyT+iQHXtF8gNJXbBJ4HI8sNhq4FYV76hNtOMIJntxf5UyaH7oFs3D8tzHTtXU2r7/PS7SM/VluusUsD3fvB8gDdQbtYnxT64SZYQ9TjTGmCxXkCVFptn/rJJPSlRHiMniDUu6yCEj/I+ks42ytVusP1hsqHMMRW6iTdVThh22JWnYkNj2Dcqp1UTYpaWkQIp5BS2FLU0J+PfAxGoX5BWSuNKfJfOg+MznYVB1F2KVBD/w2p0QmyYfFgFu3azP9E4ENNkCInqg0MDBbBh+Ih2W2YlC6jYY4qA3bC08dc9PNMdneVImWCHtKkHqnRFEZHT6ysvt9mYAhPcqmv+U+hFPFTasEqhku2d/2YwHV5BaLVY5GumcpqWrVfh+oN3a7KuoHAxOwAv6ZJfxHkaJbx16zwhHfS036lPpTI6RaOLEudL9nJMqSJ8i/fwYqI==W42X-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 29 May 11:30 +0200
Re: [bug#48696] [PATCH 1/3] doc: Structure the "Commit Access" section.
(address . 48696@debbugs.gnu.org)
878s3xhopf.fsf@gnu.org
Hi Julien & Maxime,
Julien Lepiller <julien@lepiller.eu> skribis:
Toggle quote (11 lines)>>+@example>>+git config commit.gpgsign true>>+git config user.signingkey CABBA6EA1DC0FF33>>+@end example>>+>>+You can prevent yourself from accidentally pushing unsigned commits to>>+Savannah by using the pre-push Git hook called located at>>+@file{etc/git/pre-push}:>> This sentence sounds weird. Isn't "called" superfluous?
[...]
Toggle quote (17 lines)>> +@example>> +git config commit.gpgsign true>> +git config user.signingkey CABBA6EA1DC0FF33>> +@end example>> Is that meant to represent ‘cabbage and coffee’ in l33t?> Maybe replace this with something like>> +@example>> +git config commit.gpgsign true>> +# Substitute the fingerprint of your public PGP key>> +git config user.signingkey CABBA6EA1DC0FF33>> +@end example>> Basic, I know, but people have to learn the basics from> somewhere, so maybe best be explicit here.
Yes, that makes sense to me.
Note that this text is not new, the patch merely shuffles it around.But I agree, I’ll address the two issues above once we’ve agreed on therest.
Toggle quote (5 lines)>> + [... some newlines after @section{...} ]>> These extra newlines could go directly into 'master' I guess.> The rest of [PATCH 1/3] seems ok to me?
I don’t know. :-)
Patch #1 just moves text around and adds sectioning.
BTW, the whole patch series targets ‘master’ (there’s no point indocumenting our procedures in a branch other than ‘master’).
Thanks,Ludo’.
L
L
Ludovic Courtès wrote on 29 May 11:58 +0200
Re: [bug#48696] [PATCH 3/3] doc: Explain more reasons for commit revocation.
(name . Christopher Baines)(address . mail@cbaines.net)(address . 48696@debbugs.gnu.org)
87k0nhg8uh.fsf@gnu.org
Christopher Baines <mail@cbaines.net> skribis:
Toggle quote (2 lines)> Ludovic Courtès <ludo@gnu.org> writes:
[...]
Toggle quote (16 lines)>> +Maintainers@footnote{See @uref{https://guix.gnu.org/en/about}for the>> +current list of maintainers. You can email them privately at>> +@email{guix-maintainers@@gnu.org}.} may also revoke an individual's>> +commit rights, as a last resort, if cooperation with the rest of the>> +community has caused too much friction---even within the bounds of the>> +project's code of conduct (@pxref{Contributing}). They would only do so>> +after public or private discussion with the individual and a clear>> +notice. Examples of behavior that hinders cooperation and could lead to>> +such a decision include:>> +>> +@itemize>> +@item repeated violation of the commit policy stated above;>> +@item repeated failure to take peer criticism into account;>> +@item breaching trust through a series of grave incidents.>> +@end itemize
[...]
Toggle quote (6 lines)> Since the project code of conduct sets out behavioural standards,> including mandating "Gracefully accepting constructive criticism" and> "Showing empathy towards other community members", I think that combined> with "following the relevant processes" already covers what you're> setting out here?
Note that the code of conduct does not “mandate” gracefully acceptingconstructive criticism; it merely gives it as an example of expectedbehavior.
Toggle quote (7 lines)> I was shocked by [1], which from memory is the first time a technical> measure has been used to push a contributor away from the project (at> least that's my interpretation of the effect/intent). I think the future> use of revoking individuals commit access would be good to discuss.>> 1: https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00489.html
Yes, it was the first time; it was a tough decision for usco-maintainers because it was a last resort we were not prepared for.Part of the reason for this patch is to document this possibility so weall know what to expect.
Toggle quote (5 lines)> In abstract, in my opinion, I can only think of three scenarios for> removing someones commit access when they're actively using it:>> - Clear violation of the code of conduct
Yes, that’s already covered by the code of conduct.
The section above is explicitly about cases where the individual did notviolate the code of conduct (hence “even within the bounds of theproject's code of conduct” in the text above), but instead brokecommunity expectations.
Toggle quote (2 lines)> - Suspected malicious intent
Put this way, the question becomes who is suspecting that. Instead Iwrote “breaching trust” in the bullet list above; the intent is todescribe a situation where the individual and other committers no longertrust each other, there’s no judgment involved.
Toggle quote (2 lines)> - Process problem for giving out commit access
The process for giving commit access is already documented (info "(guix)Commit Access"); my intent here was not to change it.
Thanks,Ludo’.
L
L
Ludovic Courtès wrote on 29 May 12:22 +0200
Re: [bug#48696] [PATCH 2/3] doc: Add "Addressing Mistakes" section.
(name . Christopher Baines)(address . mail@cbaines.net)(address . 48696@debbugs.gnu.org)
87eedpet69.fsf@gnu.org
Hi Chris,
Christopher Baines <mail@cbaines.net> skribis:
Toggle quote (2 lines)> Ludovic Courtès <ludo@gnu.org> writes:
[...]
Toggle quote (9 lines)>> +The Guix project values friendly cooperation and a constant effort to>> +focus on the way forward when issues arise. Committers should lead by>> +example, notably as a way to encourage contributors and contributors to>> +be. Blame as well as defensiveness do not have their place in Guix when>> +addressing genuine mistakes.>> I too would like to see less blame, but one factor is how things are> framed and the language used.
Point taken!
Toggle quote (12 lines)> On the language here, "mistake" is a word I would generally avoid if the> aim is avoid blaming someone, since mistakes are made by a person or set> of people. I'd prefer a term like "problem", since I don't perceieve> that as directly linked to a person or set of people.>> On the bit about the "person who pushed the faulty commits" (so, person> to blame...) I'd much prefer an emphisis on group responsibility to> mitigate the impact of problems quickly, and understand the factors that> led to that problems in the first place. That avoids assigning blame,> rather than the process pushing responsibility to the person to blame> ("person who pushed the faulty commit(s)").
I get what you say and very much like the idea of focusing on groupresponsibility.
There’s blame, and there’s accountability. I see group responsibilityin setting up processes and carrying out proper peer review to avoidproblems. I see accountability when it comes to commits actuallypushed—in the end, it’s one person running ‘git push’. In my view,“mistake” can be a way to name a “problem” that someone created and isaccountable for (Jelle wrote a nice message on this topic a while back).This is getting a bit philosophical though, and I’m not sure myunderstanding of English is good enough to go any further. :-)
I think you have a point though. Could you propose different wordingfor this section?
(My goal for this section was to (1) spell out circumstances that maylead to reverts, (2) explain the implications of committeraccountability, and (3) define our community standards in terms offocusing on addressing issues and not on blaming individuals.)
Toggle quote (10 lines)> On this same thread, I'd like to see less blaming in the form of asking> people to "explain". When there's a problem, and you ask someone to> explain, I would interpret that as "I'm blaming you for this, please> give your account of how the mistake was made", to which the person can> either answer explaining the details as to why they are to blame, or can> disagree with the implicit assertion that they are to blame. To avoid> assigning blame, one can just ask someone to "describe" what happened,> which I wouldn't interpret as being loaded with the same implicit> assertion.
I agree with what you write in general, though my understanding is thatyou’re not referring to the text in this patch, right?
Thanks for your feedback,Ludo’.
C
C
Christopher Baines wrote on 29 May 13:28 +0200
Re: [bug#48696] [PATCH 3/3] doc: Explain more reasons for commit revocation.
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48696@debbugs.gnu.org)
87sg25g4ni.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (34 lines)> Christopher Baines <mail@cbaines.net> skribis:>>> Ludovic Courtès <ludo@gnu.org> writes:>> [...]>>>> +Maintainers@footnote{See @uref{https://guix.gnu.org/en/about} for the>>> +current list of maintainers. You can email them privately at>>> +@email{guix-maintainers@@gnu.org}.} may also revoke an individual's>>> +commit rights, as a last resort, if cooperation with the rest of the>>> +community has caused too much friction---even within the bounds of the>>> +project's code of conduct (@pxref{Contributing}). They would only do so>>> +after public or private discussion with the individual and a clear>>> +notice. Examples of behavior that hinders cooperation and could lead to>>> +such a decision include:>>> +>>> +@itemize>>> +@item repeated violation of the commit policy stated above;>>> +@item repeated failure to take peer criticism into account;>>> +@item breaching trust through a series of grave incidents.>>> +@end itemize>> [...]>>> Since the project code of conduct sets out behavioural standards,>> including mandating "Gracefully accepting constructive criticism" and>> "Showing empathy towards other community members", I think that combined>> with "following the relevant processes" already covers what you're>> setting out here?>> Note that the code of conduct does not “mandate” gracefully accepting> constructive criticism; it merely gives it as an example of expected> behavior.
Yeah, maybe you're right. While there's a pledge regarding harassment,and the example behaviours are given in a section titled "Standards",the example behaviours are called that, examples.
Toggle quote (12 lines)>> In abstract, in my opinion, I can only think of three scenarios for>> removing someones commit access when they're actively using it:>>>> - Clear violation of the code of conduct>> Yes, that’s already covered by the code of conduct.>> The section above is explicitly about cases where the individual did not> violate the code of conduct (hence “even within the bounds of the> project's code of conduct” in the text above), but instead broke> community expectations.
I'd like to say that the code of conduct should encapsulate communityexpectations, but it does seem just to set out a strong position onharassment, and I would like to think that the community expectationsare more than just making sure people feel that they're not beingharassed.
Is your intent here for "community expectations" to be/remain abstract,or for them to be explicitly set out somewhere?
Toggle quote (7 lines)>> - Suspected malicious intent>> Put this way, the question becomes who is suspecting that. Instead I> wrote “breaching trust” in the bullet list above; the intent is to> describe a situation where the individual and other committers no longer> trust each other, there’s no judgment involved.
I think the "who" here would be the people looking at removing someonescommit access.
I like this framing because it's more specific than "breaching trustthrough a series of grave incidents". Do you have other things in mindthat this third point as you put it would cover?
Toggle quote (5 lines)>> - Process problem for giving out commit access>> The process for giving commit access is already documented (info "(guix)> Commit Access"); my intent here was not to change it.
My point here is just that I think it's reasonable to remove someonescommit access if it was effectively given out in error (because theprocess wasn't followed properly, or has been since revised).
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmCyJXFfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9XfoXw/+OQWv8R3CjNHO3tOfhbcAjttGd2+DUAGK9t+RdLEDQRtAhDC2TYv/+1iFcmEnTzKmSo0M1ea8wg/gt687nJ8qWE/2fJUstt/BFiHk7G1Oj31uDWIADcMQ5YHvcdNz8SW9CG6YN6xHP3j2HEmE4yWUo3+VihuvOUHLKqTUQvd1lZzF6IvubnlyBmqcE5As2R2qBUgM9462F/Dy+CT6ok9Rlh/dUjVRaCnJiqVdVBPUrp7UcG+ZqJKEgkWTcgC1eihIBfzDS0n96ozu9/Yz7XuF7kqKOuLglsazDR78tDVwlSk26pOxwwJbxvYaq7ZRsiGzujDVAUktHvZ7FS0r28imzF7Nq5PmJTJUBnO2GVJPxZrSVgWgGBrQJKaxzrUSnmA6favoJSmlKNFJQlSWSpFOKYnRkjFViOV1u/e0IuLDc3e63U0soaA3nBYnt/j17foN/s7bs3CbZH3QoSGYMmEHGZCw88RAqtqqexJUE7eq10Leq05EdctGtrp7PspS4JappsLh2fL0zDNrLHVk3JWKUrprSY15kV6HXWMaIhBxXCaUXVhTShLZjMoNo9ZxFOyufPugofQzx1FhiBDNPVWroRxkJ2aDHEue67o8YYtQgeVfdIIK7NUQPx1iKQXGZtvEzF3Z1/CY8JThq6pKRTaFoSvBlQx+E+Q9012iH8cplCk==4pVG-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 29 May 22:36 +0200
(name . Christopher Baines)(address . mail@cbaines.net)(address . 48696@debbugs.gnu.org)
87lf7x5lb5.fsf@gnu.org
Hello!
Christopher Baines <mail@cbaines.net> skribis:
Toggle quote (2 lines)> Ludovic Courtès <ludo@gnu.org> writes:
[...]
Toggle quote (11 lines)>> The section above is explicitly about cases where the individual did not>> violate the code of conduct (hence “even within the bounds of the>> project's code of conduct” in the text above), but instead broke>> community expectations.>> I'd like to say that the code of conduct should encapsulate community> expectations, but it does seem just to set out a strong position on> harassment, and I would like to think that the community expectations> are more than just making sure people feel that they're not being> harassed.
Yes, that’s what the code of conduct is about, mostly. It does not sayhow a development community should cooperate, how it can maximizebenefits for everyone involved. I found this article by a Rustdeveloper inspiring:https://aturon.github.io/tech/2018/06/02/listening-part-2/.
Toggle quote (3 lines)> Is your intent here for "community expectations" to be/remain abstract,> or for them to be explicitly set out somewhere?
My intent with this patch is to spell out expectations for committers,with a concrete implementation. It’s one particular aspect of“community expectations”, but one that I think ought to be written down,because committers (and maintainers) have a higher responsibility.
Toggle quote (10 lines)>>> - Suspected malicious intent>>>> Put this way, the question becomes who is suspecting that. Instead I>> wrote “breaching trust” in the bullet list above; the intent is to>> describe a situation where the individual and other committers no longer>> trust each other, there’s no judgment involved.>> I think the "who" here would be the people looking at removing someones> commit access.
Removing someone’s commit access can never be a goal. However,maintainers, like everyone else, can witness a breach of trust at somepoint.
Toggle quote (4 lines)> I like this framing because it's more specific than "breaching trust> through a series of grave incidents". Do you have other things in mind> that this third point as you put it would cover?
If repeated incidents happen, some may presume malice, while others maystill see “mere mistakes”—we have different thresholds. Breach of trustconcerns the group as a whole: once there’s mutual suspicion among somein the group, we can say that cooperation “doesn’t work” anymore, thatthere’s too much friction.
Toggle quote (9 lines)>>> - Process problem for giving out commit access>>>> The process for giving commit access is already documented (info "(guix)>> Commit Access"); my intent here was not to change it.>> My point here is just that I think it's reasonable to remove someones> commit access if it was effectively given out in error (because the> process wasn't followed properly, or has been since revised).
Oh, got it. To me it’s implicit that commit access can only be obtainedby following the documented process (that’s indeed be the case sinceit’s in place); do you think we should be more explicit?
Thanks,Ludo’.
C
C
Christopher Baines wrote on 30 May 12:29 +0200
Re: [bug#48696] [PATCH 2/3] doc: Add "Addressing Mistakes" section.
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48696@debbugs.gnu.org)
87k0ngfra8.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (43 lines)> Hi Chris,>> Christopher Baines <mail@cbaines.net> skribis:>>> Ludovic Courtès <ludo@gnu.org> writes:>> [...]>>>> +The Guix project values friendly cooperation and a constant effort to>>> +focus on the way forward when issues arise. Committers should lead by>>> +example, notably as a way to encourage contributors and contributors to>>> +be. Blame as well as defensiveness do not have their place in Guix when>>> +addressing genuine mistakes.>>>> I too would like to see less blame, but one factor is how things are>> framed and the language used.>> Point taken!>>> On the language here, "mistake" is a word I would generally avoid if the>> aim is avoid blaming someone, since mistakes are made by a person or set>> of people. I'd prefer a term like "problem", since I don't perceieve>> that as directly linked to a person or set of people.>>>> On the bit about the "person who pushed the faulty commits" (so, person>> to blame...) I'd much prefer an emphisis on group responsibility to>> mitigate the impact of problems quickly, and understand the factors that>> led to that problems in the first place. That avoids assigning blame,>> rather than the process pushing responsibility to the person to blame>> ("person who pushed the faulty commit(s)").>> I get what you say and very much like the idea of focusing on group> responsibility.>> There’s blame, and there’s accountability. I see group responsibility> in setting up processes and carrying out proper peer review to avoid> problems. I see accountability when it comes to commits actually> pushed—in the end, it’s one person running ‘git push’. In my view,> “mistake” can be a way to name a “problem” that someone created and is> accountable for (Jelle wrote a nice message on this topic a while back).> This is getting a bit philosophical though, and I’m not sure my> understanding of English is good enough to go any further. :-)
I guess part of what I'm getting at here is using language and theperspective to try and delay that inference about individualaccountability, until the discussion around a problem has reached aclear conclusion about what happened.
In doing so, opportunity is left open to actually consider the fullsituation, rather than immediately narrowing it down to what aparticular individual or group did or didn't do.
Toggle quote (8 lines)> I think you have a point though. Could you propose different wording> for this section?>> (My goal for this section was to (1) spell out circumstances that may> lead to reverts, (2) explain the implications of committer> accountability, and (3) define our community standards in terms of> focusing on addressing issues and not on blaming individuals.)
What I would like to see is more like this:
Problems happen, while minimising there occurrence is important, it's also important to respond to problems in a useful way. There are two priorities, mitigating the impact and understanding what happened in order to reduce the chance of similar incidents in the future. The responsibility for both these things primarily lies with those involved, but like everything this is a group effort.
When working to mitigate the impact of a problem, obviously the response is very much dependent on the situation. If it's possible to fix things that are broken, that's preferable. If that's infeasible, then promptly reverting changes to return to a working state is justified (as with any commit, note why the change is being made in the commit message).
Once the problem has been dealt with to some extent, then it's the responsibility of those involved to make sure the situation is understood. If you are working to understand what happened, focus on gathering information and avoid assigning any blame. Do ask those involved to describe what has happened, don't ask them to explain the situation, even if you think they have something to explain, as this implicitly blames them, which is unhelpful. Accountability comes from a consensus about the problem, learning from it and improving processes so that it's less likely to reoccur.
I'm not sure how much needs saying about reverts, but I did includesomething.
For committer accountability, that's where I'm talking about the"responsibilities of those involved". I guess that's a little vague, butwhat I'm trying to do there is trying to capture the group of relevantpeople, for example, the person who proposed the breaking change, thecommitter who pushed it, and the other person that reverted it.
In terms of trying to focus on addressing issues and not blamingindividuals, I think just avoiding language that implicitly blamespeople would be a big step forward. Whether that's enough, I'm unsure.
Toggle quote (13 lines)>> On this same thread, I'd like to see less blaming in the form of asking>> people to "explain". When there's a problem, and you ask someone to>> explain, I would interpret that as "I'm blaming you for this, please>> give your account of how the mistake was made", to which the person can>> either answer explaining the details as to why they are to blame, or can>> disagree with the implicit assertion that they are to blame. To avoid>> assigning blame, one can just ask someone to "describe" what happened,>> which I wouldn't interpret as being loaded with the same implicit>> assertion.>> I agree with what you write in general, though my understanding is that> you’re not referring to the text in this patch, right?
Yeah, although I think something to this effect might be worthincluding.
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmCzaR9fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9XePgRAAhu0dTc80nhZdC4GoRjBSJ4ZYelF6SXcnhOaW1cALPeGzRCI1Pxw4ZYDHj+cYnvvR0GmkdlcKGjGjL19ILj4O8a0DH9gs3nd7+94v4nT79uax+lvqUIXgark3s25m5TuRC4uNE6icQft5OoLmuzsYNq9cJPE+m4hUB0RmTbrQtCPMLySWbLweCMGjbAfQ7CQJbqORCaMGNeRPf9QsLHNUppw2cny9GW/D64rRaYKjFJofLAhhpb9dHr1ZM40YHWVtSO+akIIeT4nNfbxoqohJypl7QHeeP7dsdBzyJ6t+08k5q4M6WJR5Frswb3SbvB9o9CGjXqxQ71Y8RGhND5X03xaXiLU2Hj95Fq4P0LmAQP5TUxH4bzRn6Xv445FrBhR8u9NRyNXHAcRuRSQsE2Ck4YeocbWeOHkhUZvGwOOP5+PVxIyirMHSOuLPyxLQgIvvkwzVNOdSrawqb/8biFQPSEtFQjxNQD645In3PUPGjLkdOaI8X73TnFl/QvuVyE4eNDhhQ+9PAKsmzr6EQlSAtxoQ85VaLviCrVh0qogYwU7OdgZHFe6PfXxSQYAwH8LGaLWXJB/ZHFhfZ47MUBuBVHthXs9jfe68MTtMTYfNeopg5XJbqs/kwUUp6ICnVyfUOm11QXFKksM3CGVs4XfzUtk8VEMPCRKUwvyuU8XcFJE==8m4C-----END PGP SIGNATURE-----
T
T
Tobias Geerinckx-Rice wrote on 30 May 14:49 +0200
Re: [bug#48696] [PATCH 0/3] Documenting commit reverts and revocation
(name . Ludovic Courtès)(address . ludo@gnu.org)
87wnrgs7yb.fsf@nckx
Ludovic Courtès 写道:
Toggle quote (5 lines)> It essentially codifies unwritten rules, but as always, I think > it’s> better to be explicit about the rules and community > expectations.
Looks good to me modulo obvious typos like the ‘called’ pointed out by Julien.
I *don't* think the text assigns too much potential blame. Responsibility, yes.
Thanks Ludo'!
T G-R
-----BEGIN PGP SIGNATURE-----
iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYLOJvA0cbWVAdG9iaWFzLmdyAAoJEA2w/4hPVW15nCEBAJCQXqDsk05JSkMY5Fred19XhZQwFpu20IHhvGNxVXIvAP9H4Rt8mIq04zTr4/q3XVnhh7Pqj1PYLu5Z1xd8aIL+DQ===ifZ8-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 2 Jun 11:22 +0200
Re: bug#48696: [PATCH 0/3] Documenting commit reverts and revocation
(name . Christopher Baines)(address . mail@cbaines.net)(address . 48696@debbugs.gnu.org)
87tumgwrhh.fsf_-_@gnu.org
Hi Chris,
Christopher Baines <mail@cbaines.net> skribis:
Toggle quote (2 lines)> Ludovic Courtès <ludo@gnu.org> writes:
[...]
Toggle quote (47 lines)>> I think you have a point though. Could you propose different wording>> for this section?>>>> (My goal for this section was to (1) spell out circumstances that may>> lead to reverts, (2) explain the implications of committer>> accountability, and (3) define our community standards in terms of>> focusing on addressing issues and not on blaming individuals.)>> What I would like to see is more like this:>> Problems happen, while minimising there occurrence is important, it's> also important to respond to problems in a useful way. There are two> priorities, mitigating the impact and understanding what happened in> order to reduce the chance of similar incidents in the future. The> responsibility for both these things primarily lies with those> involved, but like everything this is a group effort.>> When working to mitigate the impact of a problem, obviously the> response is very much dependent on the situation. If it's possible to> fix things that are broken, that's preferable. If that's infeasible,> then promptly reverting changes to return to a working state is> justified (as with any commit, note why the change is being made in> the commit message).>> Once the problem has been dealt with to some extent, then it's the> responsibility of those involved to make sure the situation is> understood. If you are working to understand what happened, focus on> gathering information and avoid assigning any blame. Do ask those> involved to describe what has happened, don't ask them to explain the> situation, even if you think they have something to explain, as this> implicitly blames them, which is unhelpful. Accountability comes from> a consensus about the problem, learning from it and improving> processes so that it's less likely to reoccur.>> I'm not sure how much needs saying about reverts, but I did include> something.>> For committer accountability, that's where I'm talking about the> "responsibilities of those involved". I guess that's a little vague, but> what I'm trying to do there is trying to capture the group of relevant> people, for example, the person who proposed the breaking change, the> committer who pushed it, and the other person that reverted it.>> In terms of trying to focus on addressing issues and not blaming> individuals, I think just avoiding language that implicitly blames> people would be a big step forward. Whether that's enough, I'm unsure.
OK.
I like what you wrote; I think it addresses #3 and a bit of #2 above,but I find a bit too abstract, not sufficiently hands-on (when cancommits be reverted? what’s the timeframe? who’s involved?), and lackingexamples. “Problems happen” sounds unspecific to me (it reminds me ofForest Gump :-)) and I’m uncomfortable with the passive voice that tendsto erase individuals.
@subsection Addressing Issues Peer review (@pxref{Submitting Patches}) and tools such as @command{guix lint} (@pxref{Invoking guix lint}) and the test suite (@pxref{Running the Test Suite}) should catch issues before they are pushed. Yet, commits that ``break'' functionality might occasionally go through. When that happens, there are two priorities: mitigating the impact, and understanding what happened to reduce the chance of similar incidents in the future. The responsibility for both these things primarily lies with those involved, but like everything this is a group effort. Some issues can directly affect all users---for instance because they make @command{guix pull} fail or break core functionality, because they break major packages (at build time or run time), or because they introduce known security vulnerabilities. @cindex reverting commits The people involved in authoring, reviewing, and pushing such commit(s) should be at the forefront to mitigate their impact in a timely fashion: by pushing a followup commit to fix it (if possible), or by reverting it to leave time to come up with a proper fix, and by communicating with other developers about the problem. If these persons are unavailable to address the issue in time, other committers are entitled to revert the commit(s), explaining in the commit log and on the mailing list what the problem was, with the goal of leaving time to the original committer, reviewer(s), and author(s) to propose a way forward. Once the problem has been dealt with, it is the responsibility of those involved to make sure the situation is understood. If you are working to understand what happened, focus on gathering information and avoid assigning any blame. Do ask those involved to describe what happened, do not ask them to explain the situation---this would implicitly blame them, which is unhelpful. Accountability comes from a consensus about the problem, learning from it and improving processes so that it's less likely to reoccur.
There’s still “the people involved”, “these persons”, and “such commits”(I removed “faulty”), because I couldn’t think of a way of avoidingthese without making the text too abstract or dismissing the ideaentirely (the idea that if I push a breaking change, others can expectme to be spend time “mitigating the effort”).
Also, I think it’s useful to distinguish between “I revert my commit”and “someone reverts my commit” due to their different social andemotional implications (our goal is precisely to suggest that theseimplications are out of place in this group effort that Guix is, but wecan’t deny that they preexist).
WDYT?
Thanks for taking the time to work on it!
Ludo’.
C
C
Christopher Baines wrote on 8 Jun 16:02 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48696@debbugs.gnu.org)
87bl8gtpxk.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (81 lines)> Hi Chris,>> Christopher Baines <mail@cbaines.net> skribis:>>> Ludovic Courtès <ludo@gnu.org> writes:>> [...]>>>> I think you have a point though. Could you propose different wording>>> for this section?>>>>>> (My goal for this section was to (1) spell out circumstances that may>>> lead to reverts, (2) explain the implications of committer>>> accountability, and (3) define our community standards in terms of>>> focusing on addressing issues and not on blaming individuals.)>>>> What I would like to see is more like this:>>>> Problems happen, while minimising there occurrence is important, it's>> also important to respond to problems in a useful way. There are two>> priorities, mitigating the impact and understanding what happened in>> order to reduce the chance of similar incidents in the future. The>> responsibility for both these things primarily lies with those>> involved, but like everything this is a group effort.>>>> When working to mitigate the impact of a problem, obviously the>> response is very much dependent on the situation. If it's possible to>> fix things that are broken, that's preferable. If that's infeasible,>> then promptly reverting changes to return to a working state is>> justified (as with any commit, note why the change is being made in>> the commit message).>>>> Once the problem has been dealt with to some extent, then it's the>> responsibility of those involved to make sure the situation is>> understood. If you are working to understand what happened, focus on>> gathering information and avoid assigning any blame. Do ask those>> involved to describe what has happened, don't ask them to explain the>> situation, even if you think they have something to explain, as this>> implicitly blames them, which is unhelpful. Accountability comes from>> a consensus about the problem, learning from it and improving>> processes so that it's less likely to reoccur.>>>> I'm not sure how much needs saying about reverts, but I did include>> something.>>>> For committer accountability, that's where I'm talking about the>> "responsibilities of those involved". I guess that's a little vague, but>> what I'm trying to do there is trying to capture the group of relevant>> people, for example, the person who proposed the breaking change, the>> committer who pushed it, and the other person that reverted it.>>>> In terms of trying to focus on addressing issues and not blaming>> individuals, I think just avoiding language that implicitly blames>> people would be a big step forward. Whether that's enough, I'm unsure.>> OK.>> I like what you wrote; I think it addresses #3 and a bit of #2 above,> but I find a bit too abstract, not sufficiently hands-on (when can> commits be reverted? what’s the timeframe? who’s involved?), and lacking> examples. “Problems happen” sounds unspecific to me (it reminds me of> Forest Gump :-)) and I’m uncomfortable with the passive voice that tends> to erase individuals.>> @subsection Addressing Issues>> Peer review (@pxref{Submitting Patches}) and tools such as> @command{guix lint} (@pxref{Invoking guix lint}) and the test suite> (@pxref{Running the Test Suite}) should catch issues before they are> pushed. Yet, commits that ``break'' functionality might occasionally> go through. When that happens, there are two priorities: mitigating> the impact, and understanding what happened to reduce the chance of> similar incidents in the future. The responsibility for both these> things primarily lies with those involved, but like everything this is> a group effort.> > Some issues can directly affect all users---for instance because they> make @command{guix pull} fail or break core functionality, because they> break major packages (at build time or run time), or because they> introduce known security vulnerabilities.
I'm not sure what this paragraph is getting at?
In any case, for security vulnerabilities, to affect all users theywould also have to occur in major packages.
Toggle quote (36 lines)> @cindex reverting commits> The people involved in authoring, reviewing, and pushing such> commit(s) should be at the forefront to mitigate their impact in a> timely fashion: by pushing a followup commit to fix it (if possible),> or by reverting it to leave time to come up with a proper fix, and by> communicating with other developers about the problem.> > If these persons are unavailable to address the issue in time, other> committers are entitled to revert the commit(s), explaining in the> commit log and on the mailing list what the problem was, with the goal> of leaving time to the original committer, reviewer(s), and author(s)> to propose a way forward.> > Once the problem has been dealt with, it is the responsibility of> those involved to make sure the situation is understood. If you are> working to understand what happened, focus on gathering information> and avoid assigning any blame. Do ask those involved to describe what> happened, do not ask them to explain the situation---this would> implicitly blame them, which is unhelpful. Accountability comes from> a consensus about the problem, learning from it and improving> processes so that it's less likely to reoccur.>> There’s still “the people involved”, “these persons”, and “such commits”> (I removed “faulty”), because I couldn’t think of a way of avoiding> these without making the text too abstract or dismissing the idea> entirely (the idea that if I push a breaking change, others can expect> me to be spend time “mitigating the effort”).>> Also, I think it’s useful to distinguish between “I revert my commit”> and “someone reverts my commit” due to their different social and> emotional implications (our goal is precisely to suggest that these> implications are out of place in this group effort that Guix is, but we> can’t deny that they preexist).>> WDYT?
I think the above text looks good. As noted above, I'm unsure about thesecond paragraph, but that's not a big issue.
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmC/eHdfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9XfDTA/8DCO0CBrXvyvu5JlgJqJIzeoH9Wf5gv5NPRMaF4uCbcLE5DiFg9RYgy1UpYedqbSXx1Cfr6mmJw/t5ObaIBrOsnqAO9FF1+2Tj91A9x9nTY/kkP0Cq0r96JNIX7l/ht3REeEYwUrtS4Gw0lE8zK6PZck8LPNGDopuhHfM8P/BxpREpAhvPhTsb2VSv8z8HC1qGhW587DRGbW9WlNr/qADVMqOhpvu4K3g5Be8J+wbv5E4DrkV9d5tSN0SSMCg0MsaixoO44iQqilSTNhkRic2BEV1YGRq9JyZ1RocMBpTPBYnOjiK/vSySoSDkk8aSEnb2mL6HosXXYfFyYvhbeXHJw8LFkcr/worayJ55WFzKVO6CPSX9v7WgVtl6Aupl0sOxlLLq3gR6jHDeuZNWGjpAX/BBMeeijiJVyRr7zVRDC85RyXxJokVSlXECbqO3xuOyJbTZP7yvc4sSO3gffHyMQQ/6GUX0cKKCGjdyTBCqpF4d9dWULtV1n87h8OcUrzkszCbPXjjZ+eQTQjkytiUPiGSAoz/EDs50hqjDCo1qpcfIMUOkEjolv8U0CfMjU4lZ83V6MGiRPCfCFzezh+ZSqHEp8qk/RG0qamW4+XnEOFMrH4VB78i2C/sbnWlxyyRif8I9NMwNH7WDWl6i4Svb/Lr9rO5zVSrznXKZm6Jzzo==YZ9K-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 11 Jun 16:05 +0200
(name . Christopher Baines)(address . mail@cbaines.net)(address . 48696@debbugs.gnu.org)
87lf7g7azx.fsf@gnu.org
Hi Chris,
Christopher Baines <mail@cbaines.net> skribis:
Toggle quote (2 lines)> Ludovic Courtès <ludo@gnu.org> writes:
[...]
Toggle quote (19 lines)>> @subsection Addressing Issues>>>> Peer review (@pxref{Submitting Patches}) and tools such as>> @command{guix lint} (@pxref{Invoking guix lint}) and the test suite>> (@pxref{Running the Test Suite}) should catch issues before they are>> pushed. Yet, commits that ``break'' functionality might occasionally>> go through. When that happens, there are two priorities: mitigating>> the impact, and understanding what happened to reduce the chance of>> similar incidents in the future. The responsibility for both these>> things primarily lies with those involved, but like everything this is>> a group effort.>> >> Some issues can directly affect all users---for instance because they>> make @command{guix pull} fail or break core functionality, because they>> break major packages (at build time or run time), or because they>> introduce known security vulnerabilities.>> I'm not sure what this paragraph is getting at?
It’s supposed to be provide concrete guidance to a committer wonderingwhether they can/should/are entitled to revert a given commit.
Toggle quote (3 lines)> In any case, for security vulnerabilities, to affect all users they> would also have to occur in major packages.
Agreed. The word “known” is important here: if I remove *-CVE-*.patch,or if I downgrade a package, I’m likely introducing a “known”vulnerability; if I’m adding a new package that later happens to bevulnerable, it’s not a “known” vulnerability (it’s just routine ;-)).
Toggle quote (3 lines)> I think the above text looks good. As noted above, I'm unsure about the> second paragraph, but that's not a big issue.
OK, thanks for taking the time to discuss it. I’ll send a v2 soeveryone gets a chance to chime in.
Ludo’.
L
L
Ludovic Courtès wrote on 13 Jun 12:15 +0200
[PATCH v2 0/4] Documenting commit reverts and revocation
(address . 48696@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
20210613101538.10668-1-ludo@gnu.org
Hi!
Changes since the initial version:
1. “Addressing Mistakes” section replaced by “Addressing Issues” following suggestions by Chris Baines at https://issues.guix.gnu.org/48696#17.
2. Fix typo and clarify Git commit signing instructions as reported by Julien and Maxime (these were in pre-existing text).
If there are no objections, I’d like to push within a couple ofdays.
Thanks,Ludo’.
Ludovic Courtès (4): doc: Structure the "Commit Access" section. doc: Add "Addressing Issues" section. doc: Explain more reasons for commit revocation. doc: Clarify Git commit signing; fix typo.
doc/contributing.texi | 121 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 100 insertions(+), 21 deletions(-)
-- 2.32.0
L
L
Ludovic Courtès wrote on 13 Jun 12:15 +0200
[PATCH v2 1/4] doc: Structure the "Commit Access" section.
(address . 48696@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
20210613101538.10668-2-ludo@gnu.org
* doc/contributing.texi (Commit Access): Add introduction and sectionheading. Separate OpenPGP setup from commit policy.--- doc/contributing.texi | 59 ++++++++++++++++++++++++++++--------------- 1 file changed, 38 insertions(+), 21 deletions(-)
Toggle diff (99 lines)diff --git a/doc/contributing.texi b/doc/contributing.texiindex d67e632520..4ab489173b 100644--- a/doc/contributing.texi+++ b/doc/contributing.texi@@ -1275,8 +1275,19 @@ this nifty tool! @section Commit Access @cindex commit access, for developers-For frequent contributors, having write access to the repository is-convenient. When you deem it necessary, consider applying for commit+Everyone can contribute to Guix without having commit access+(@pxref{Submitting Patches}). However, for frequent contributors,+having write access to the repository can be convenient. Commit access+should not be thought of as a ``badge of honor'' but rather as a+responsibility a contributor is willing to take to help the project.++The following sections explain how to get commit access, how to be ready+to push commits, and the policies and community expectations for commits+pushed upstream.++@subsection Applying for Commit Access++When you deem it necessary, consider applying for commit access by following these steps: @enumerate@@ -1348,6 +1359,27 @@ review and merging system, which, as a consequence, may lead us to have fewer people with commit access to the main repository. Stay tuned! @end quotation +All commits that are pushed to the central repository on Savannah must+be signed with an OpenPGP key, and the public key should be uploaded to+your user account on Savannah and to public key servers, such as+@code{keys.openpgp.org}. To configure Git to automatically sign+commits, run:++@example+git config commit.gpgsign true+git config user.signingkey CABBA6EA1DC0FF33+@end example++You can prevent yourself from accidentally pushing unsigned commits to+Savannah by using the pre-push Git hook called located at+@file{etc/git/pre-push}:++@example+cp etc/git/pre-push .git/hooks/pre-push+@end example++@subsection Commit Policy+ If you get commit access, please make sure to follow the policy below (discussions of the policy can take place on @email{guix-devel@@gnu.org}).@@ -1366,25 +1398,6 @@ mailing list for commit notifications (@email{guix-commits@@gnu.org}), so people can notice. Before pushing your changes, make sure to run @code{git pull --rebase}. -All commits that are pushed to the central repository on Savannah must-be signed with an OpenPGP key, and the public key should be uploaded to-your user account on Savannah and to public key servers, such as-@code{keys.openpgp.org}. To configure Git to automatically sign-commits, run:--@example-git config commit.gpgsign true-git config user.signingkey CABBA6EA1DC0FF33-@end example--You can prevent yourself from accidentally pushing unsigned commits to-Savannah by using the pre-push Git hook called located at-@file{etc/git/pre-push}:--@example-cp etc/git/pre-push .git/hooks/pre-push-@end example- When pushing a commit on behalf of somebody else, please add a @code{Signed-off-by} line at the end of the commit log message---e.g., with @command{git am --signoff}. This improves tracking of who did@@ -1406,12 +1419,16 @@ you're confident, it's OK to commit. That last part is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with. +@subsection Commit Revocation+ In order to reduce the possibility of mistakes, committers will have their Savannah account removed from the Guix Savannah project and their key removed from @file{.guix-authorizations} after 12 months of inactivity; they can ask to regain commit access by emailing the maintainers, without going through the vouching process. +@subsection Helping Out+ One last thing: the project keeps moving forward because committers not only push their own awesome changes, but also offer some of their time @emph{reviewing} and pushing other people's changes. As a committer,-- 2.32.0
L
L
Ludovic Courtès wrote on 13 Jun 12:15 +0200
[PATCH v2 3/4] doc: Explain more reasons for commit revocation.
(address . 48696@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
20210613101538.10668-4-ludo@gnu.org
* doc/contributing.texi (Commit Revocation): Expound.--- doc/contributing.texi | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
Toggle diff (34 lines)diff --git a/doc/contributing.texi b/doc/contributing.texiindex 00962be11e..5e59278534 100644--- a/doc/contributing.texi+++ b/doc/contributing.texi@@ -1466,6 +1466,27 @@ key removed from @file{.guix-authorizations} after 12 months of inactivity; they can ask to regain commit access by emailing the maintainers, without going through the vouching process. +Maintainers@footnote{See @uref{https://guix.gnu.org/en/about} for the+current list of maintainers. You can email them privately at+@email{guix-maintainers@@gnu.org}.} may also revoke an individual's+commit rights, as a last resort, if cooperation with the rest of the+community has caused too much friction---even within the bounds of the+project's code of conduct (@pxref{Contributing}). They would only do so+after public or private discussion with the individual and a clear+notice. Examples of behavior that hinders cooperation and could lead to+such a decision include:++@itemize+@item repeated violation of the commit policy stated above;+@item repeated failure to take peer criticism into account;+@item breaching trust through a series of grave incidents.+@end itemize++When maintainers resort to such a decision, they notify developers on+@email{guix-devel@@gnu.org}; inquiries may be sent to+@email{guix-maintainers@@gnu.org}. Depending on the situation, the+individual may still be welcome to contribute.+ @subsection Helping Out One last thing: the project keeps moving forward because committers not-- 2.32.0
L
L
Ludovic Courtès wrote on 13 Jun 12:15 +0200
[PATCH v2 4/4] doc: Clarify Git commit signing; fix typo.
(address . 48696@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
20210613101538.10668-5-ludo@gnu.org
Suggested by Maxime Devos <maximedevos@telenet.be>and Julien Lepiller <julien@lepiller.eu>.
* doc/contributing.texi (Commit Access): Clarify Git commit signingsetup and fix typo.--- doc/contributing.texi | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Toggle diff (21 lines)diff --git a/doc/contributing.texi b/doc/contributing.texiindex 5e59278534..a8bc279936 100644--- a/doc/contributing.texi+++ b/doc/contributing.texi@@ -1367,11 +1367,13 @@ commits, run: @example git config commit.gpgsign true++# Substitute the fingerprint of your public PGP key. git config user.signingkey CABBA6EA1DC0FF33 @end example You can prevent yourself from accidentally pushing unsigned commits to-Savannah by using the pre-push Git hook called located at+Savannah by using the pre-push Git hook located at @file{etc/git/pre-push}: @example-- 2.32.0
L
L
Ludovic Courtès wrote on 13 Jun 12:15 +0200
[PATCH v2 2/4] doc: Add "Addressing Issues" section.
(address . 48696@debbugs.gnu.org)
20210613101538.10668-3-ludo@gnu.org
* doc/contributing.texi (Addressing Mistakes): New section.
Co-authored-by: Christopher Baines <mail@cbaines.net>--- doc/contributing.texi | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
Toggle diff (52 lines)diff --git a/doc/contributing.texi b/doc/contributing.texiindex 4ab489173b..00962be11e 100644--- a/doc/contributing.texi+++ b/doc/contributing.texi@@ -1419,6 +1419,45 @@ you're confident, it's OK to commit. That last part is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with. +@subsection Addressing Issues++Peer review (@pxref{Submitting Patches}) and tools such as+@command{guix lint} (@pxref{Invoking guix lint}) and the test suite+(@pxref{Running the Test Suite}) should catch issues before they are+pushed. Yet, commits that ``break'' functionality might occasionally+go through. When that happens, there are two priorities: mitigating+the impact, and understanding what happened to reduce the chance of+similar incidents in the future. The responsibility for both these+things primarily lies with those involved, but like everything this is+a group effort.++Some issues can directly affect all users---for instance because they+make @command{guix pull} fail or break core functionality, because they+break major packages (at build time or run time), or because they+introduce known security vulnerabilities.++@cindex reverting commits+The people involved in authoring, reviewing, and pushing such+commit(s) should be at the forefront to mitigate their impact in a+timely fashion: by pushing a followup commit to fix it (if possible),+or by reverting it to leave time to come up with a proper fix, and by+communicating with other developers about the problem.++If these persons are unavailable to address the issue in time, other+committers are entitled to revert the commit(s), explaining in the+commit log and on the mailing list what the problem was, with the goal+of leaving time to the original committer, reviewer(s), and author(s)+to propose a way forward.++Once the problem has been dealt with, it is the responsibility of+those involved to make sure the situation is understood. If you are+working to understand what happened, focus on gathering information+and avoid assigning any blame. Do ask those involved to describe what+happened, do not ask them to explain the situation---this would+implicitly blame them, which is unhelpful. Accountability comes from+a consensus about the problem, learning from it and improving+processes so that it's less likely to reoccur.+ @subsection Commit Revocation In order to reduce the possibility of mistakes, committers will have-- 2.32.0
X
X
Xinglu Chen wrote on 13 Jun 13:50 +0200
Re: [bug#48696] [PATCH v2 1/4] doc: Structure the "Commit Access" section.
(name . Ludovic Courtès)(address . ludo@gnu.org)
87pmwq7zkx.fsf@yoctocell.xyz
On Sun, Jun 13 2021, Ludovic Courtès wrote:
Toggle quote (51 lines)> * doc/contributing.texi (Commit Access): Add introduction and section> heading. Separate OpenPGP setup from commit policy.> ---> doc/contributing.texi | 59 ++++++++++++++++++++++++++++---------------> 1 file changed, 38 insertions(+), 21 deletions(-)>> diff --git a/doc/contributing.texi b/doc/contributing.texi> index d67e632520..4ab489173b 100644> --- a/doc/contributing.texi> +++ b/doc/contributing.texi> @@ -1275,8 +1275,19 @@ this nifty tool!> @section Commit Access> > @cindex commit access, for developers> -For frequent contributors, having write access to the repository is> -convenient. When you deem it necessary, consider applying for commit> +Everyone can contribute to Guix without having commit access> +(@pxref{Submitting Patches}). However, for frequent contributors,> +having write access to the repository can be convenient. Commit access> +should not be thought of as a ``badge of honor'' but rather as a> +responsibility a contributor is willing to take to help the project.> +> +The following sections explain how to get commit access, how to be ready> +to push commits, and the policies and community expectations for commits> +pushed upstream.> +> +@subsection Applying for Commit Access> +> +When you deem it necessary, consider applying for commit> access by following these steps:> > @enumerate> @@ -1348,6 +1359,27 @@ review and merging system, which, as a consequence, may lead us to have> fewer people with commit access to the main repository. Stay tuned!> @end quotation> > +All commits that are pushed to the central repository on Savannah must> +be signed with an OpenPGP key, and the public key should be uploaded to> +your user account on Savannah and to public key servers, such as> +@code{keys.openpgp.org}. To configure Git to automatically sign> +commits, run:> +> +@example> +git config commit.gpgsign true> +git config user.signingkey CABBA6EA1DC0FF33> +@end example> +> +You can prevent yourself from accidentally pushing unsigned commits to> +Savannah by using the pre-push Git hook called located at> +@file{etc/git/pre-push}:
I think you forgot to remove “called” :)
-----BEGIN PGP SIGNATURE-----
iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmDF8R4VHHB1YmxpY0B5b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5+lYQAJ18HEKqv51A2NJmMw0r/TksInNg3fLQsc3+dgWM7mODkQINeR26gPX8tDO88H8XjUniD1Os01BEetr4NUKwlcDWqjc3rPrHd4a0rOZZKKYuZuYXyrT3A6mWuxTsq6slKi8zk77bj6vIiWerGaBruBJMvxuFwrzv6jB4B2xlcZR6vvbSC4GgnIt296+y/nYRTYUMr0tW2faZVKjNQ3EnHbZ5b5E/A9/qT+kvWC8XWjdbpbgBdv0l/Y3d0yTavW3IxgU3d3OCorQ8UOrcYCicqu3VAgZU4glX0Lu2Tk8D3AvDlQ9b7sCzGoPXyPQcoHs8jiBCSImUsX3iYZEpicFRwoot7zfo+evSoKB5r77QSp/mU4nr9tHztvKUt97/009jkrtzIk+hV+3uZs9/rd5b38VIwk4jG7YNMWrDaN8G698BM1I+znjDiAsSST7WIKnmXCQuYENA/BpRdcSU3hqEG2GeQyVsNAbGyZFfyhX+LnWsjTQMoVkceurt+OYOFMruU7YT8WRx+nCpw1KUjT5OeWOkM3MhfAKTi1eUbPbkkQwL8D0Z13R4gfyatW/b3aAKF/M39bDnWUZwqYsqQjHSIQGNNicfz9PuTrXgt+kdwqDNnK0AMRtL/MyC/wdiSvpGhbiPcgMQgfO5lLfheh+V1WkHJ2/QsTAwGEtBzNzrXByu=QmEv-----END PGP SIGNATURE-----
X
X
Xinglu Chen wrote on 13 Jun 13:56 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)
87lf7e7zb9.fsf@yoctocell.xyz
On Sun, Jun 13 2021, Xinglu Chen wrote:
Toggle quote (55 lines)> On Sun, Jun 13 2021, Ludovic Courtès wrote:>>> * doc/contributing.texi (Commit Access): Add introduction and section>> heading. Separate OpenPGP setup from commit policy.>> --->> doc/contributing.texi | 59 ++++++++++++++++++++++++++++--------------->> 1 file changed, 38 insertions(+), 21 deletions(-)>>>> diff --git a/doc/contributing.texi b/doc/contributing.texi>> index d67e632520..4ab489173b 100644>> --- a/doc/contributing.texi>> +++ b/doc/contributing.texi>> @@ -1275,8 +1275,19 @@ this nifty tool!>> @section Commit Access>> >> @cindex commit access, for developers>> -For frequent contributors, having write access to the repository is>> -convenient. When you deem it necessary, consider applying for commit>> +Everyone can contribute to Guix without having commit access>> +(@pxref{Submitting Patches}). However, for frequent contributors,>> +having write access to the repository can be convenient. Commit access>> +should not be thought of as a ``badge of honor'' but rather as a>> +responsibility a contributor is willing to take to help the project.>> +>> +The following sections explain how to get commit access, how to be ready>> +to push commits, and the policies and community expectations for commits>> +pushed upstream.>> +>> +@subsection Applying for Commit Access>> +>> +When you deem it necessary, consider applying for commit>> access by following these steps:>> >> @enumerate>> @@ -1348,6 +1359,27 @@ review and merging system, which, as a consequence, may lead us to have>> fewer people with commit access to the main repository. Stay tuned!>> @end quotation>> >> +All commits that are pushed to the central repository on Savannah must>> +be signed with an OpenPGP key, and the public key should be uploaded to>> +your user account on Savannah and to public key servers, such as>> +@code{keys.openpgp.org}. To configure Git to automatically sign>> +commits, run:>> +>> +@example>> +git config commit.gpgsign true>> +git config user.signingkey CABBA6EA1DC0FF33>> +@end example>> +>> +You can prevent yourself from accidentally pushing unsigned commits to>> +Savannah by using the pre-push Git hook called located at>> +@file{etc/git/pre-push}:>> I think you forgot to remove “called” :)
Oh, I see that you fixed it in 4/4...
-----BEGIN PGP SIGNATURE-----
iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmDF8noVHHB1YmxpY0B5b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x507sP/240aYijA3YYBPAxA1RiSY0cH8tt8OsZzvJQn5U0KLfLLd0UyL+mAMzP3/rPO7tYJNKtaRE5q3gW6Fm0VLYWHhuZsglone1JOM1/VZPt37YeF0RAiZZwvvlSVHEHVz8RlvEvzz/Tm1xgMW+zooGbwmLxSUaPgm4g7sXGAePx8Yxio6DwKka9yxOcnH17NKotjb4oD3+RrE7xzoH0/vOKQ/WnQcTIfNDMP17Rmh5iD5yZub5x20hxswN9LBUUxW0eNR93XboFxokKhjUAZhpkGSXvXIbXlFNHBqPSGk909xRpvsIrFCd2zct/bjC/SuhqrPNVEth18/ffxsKZH253Jc+YPMrEV7m4vYpaduyTJptbxIwZWPgNC9Ofv6u5yvKPTeKBSDMGVoC+hRITKaLP0b606faYgXuLGOM9Xb2N/l4sjWP8imnDf+442qWn2N90TR/BG0+v4mR3sXOKO0v+AX0BdrtBaoAQ83Qs0SBn0K7OmuKOwATNdmuxonh/H3m8lKQ4oKMaUhiect06/4U71QGvjD9Oy/jPo/RqZgRxdWy5EDVFCcBpnaZVYQ+0BVHfU3m1RjkiOFQcin1CpkrssA0rzwYUOsdMEXb7cRmXXkllswy+NyabhcYOYIY90V0SZJx4cbgbfCYJ/573nqNYhkEJ1SJCfLFgm89U02w8j4UE=Rwav-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 18 Jun 14:37 +0200
Re: bug#48696: [PATCH 0/3] Documenting commit reverts and revocation
(address . 48696-done@debbugs.gnu.org)
87eeczfivx.fsf_-_@gnu.org
Hi!
Ludovic Courtès <ludo@gnu.org> skribis:
Toggle quote (3 lines)> If there are no objections, I’d like to push within a couple of> days.
[...]
Toggle quote (5 lines)> doc: Structure the "Commit Access" section.> doc: Add "Addressing Issues" section.> doc: Explain more reasons for commit revocation.> doc: Clarify Git commit signing; fix typo.
Pushed as b5b9266e409abb18970bd34557cf087eb29fa713.
Thanks Chris and everyone for your feedback!
Ludo’.
Closed
?