Zen

Source string Source string

323/10000 · 323

The string is read only.

English Actions
# Substitute the fingerprint of your public PGP key.
git config user.signingkey CABBA6EA1DC0FF33
To check that commits are signed with correct key, use:
@xref{Building from Git} for running the first authentication of a Guix checkout.
To avoid accidentally pushing unsigned or signed with the wrong key commits to Savannah, make sure to configure Git according to @xref{Configuring Git}.
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}).
Ensure you're aware of how the changes should be handled (@pxref{Managing Patches and Branches}) prior to being pushed to the repository, especially for the @code{master} branch.
If you're committing and pushing your own changes, try and wait at least one week (two weeks for more significant changes, up to one month for changes such as removing a package---@pxref{package-removal-policy, Package Removal}) after you send them for review. After this, if no one else is available to review them and if you're confident about the changes, it's OK to commit.
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 what.
When adding channel news entries (@pxref{Channels, Writing Channel News}), make sure they are well-formed by running the following command right before pushing:
make check-channel-news
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.
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.
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.
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:
repeated violation of the commit policy stated above;
repeated failure to take peer criticism into account;
breaching trust through a series of grave incidents.
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.
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, you're welcome to use your expertise and commit rights to help other contributors, too!
Perhaps the biggest action you can do to help GNU Guix grow as a project is to review the work contributed by others. You do not need to be a committer to do so; applying, reading the source, building, linting and running other people's series and sharing your comments about your experience will give some confidence to committers. You must ensure the check list found in the @ref{Submitting Patches} section has been correctly followed. A reviewed patch series should give the best chances for the proposed change to be merged faster, so if a change you would like to see merged hasn't yet been reviewed, this is the most appropriate thing to do! If you would like to review changes in a specific area and to receive notifications for incoming patches relevant to that domain, consider joining the relevant team(s) (@pxref{Teams}).
reviewing, guidelines
Review comments should be unambiguous; be as clear and explicit as you can about what you think should be changed, ensuring the author can take action on it. Please try to keep the following guidelines in mind during review:
@emph{Be clear and explicit about changes you are suggesting}, ensuring the author can take action on it. In particular, it is a good idea to explicitly ask for new revisions when you want it.

Loading…

No matching activity found.
Browse all string changes

Things to check

Unpluralised

The string is used as plural, but not using plural forms

Reset

Glossary

English English
No related strings found in the glossary.

8312200 String information

Source string description
type: Plain text
Flags
read-only
Source string location
guix-git/doc/contributing.texi:2932
String age
3 years ago
Last updated
8 days ago
Source string age
3 years ago
Translation file
po/doc/guix-manual.pot, string 779