Changes should be posted to email@example.com. This mailing
list fills the patch-tracking database (voir L’outil de gestion des défauts). It also
allows patches to be picked up and tested by the quality assurance tooling;
the result of that testing eventually shows up on the dashboard at
ISSUE_NUMBER is the number assigned by the issue tracker. Leave time
for a review, without committing anything.
As an exception, some changes considered “trivial” or “obvious” may be
pushed directly to the
master branch. This includes changes to fix
typos and reverting commits that caused immediate problems. This is subject
to being adjusted, allowing individuals to commit directly on
non-controversial changes on parts they’re familiar with.
Changes which affect more than 300 dependent packages (voir Invoquer
guix refresh) should first be pushed to a topic branch other than
the set of changes should be consistent—e.g., “GNOME update”, “NumPy
update”, etc. This allows for testing: the branch will automatically show
up at ‘
https://qa.guix.gnu.org/branch/branch’, with an
indication of its build status on various platforms.
To help coordinate the merging of branches, you must create a new guix-patches issue each time you wish to merge a branch (voir L’outil de gestion des défauts). The title of the issue requesting to merge a branch should have the following format:
Request for merging "name" branch
The QA infrastructure recognizes such issues and lists the merge requests on its main page. Normally branches will be merged in a “first come, first merged” manner, tracked through the guix-patches issues.
If you agree on a different order with those involved, you can track this by updating which issues block45 which other issues. Therefore, to know which branch is at the front of the queue, look for the oldest issue, or the issue that isn’t blocked by any other branch merges. An ordered list of branches with the open issues is available at https://qa.guix.gnu.org.
Once a branch is at the front of the queue, wait until sufficient time has
passed for the build farms to have processed the changes, and for the
necessary testing to have happened. For example, you can check
https://qa.guix.gnu.org/branch/branch’ to see information
on some builds and substitute availability.
You can mark an issue as blocked by
another by emailing firstname.lastname@example.org with the following line
in the body of the email:
block XXXXX by YYYYY. Where
is the number for the blocked issue, and
YYYYY is the number for the
issue blocking it.