| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Move existing entries.
|
|
|
|
The azure OSX job replaces the first travis job, and the second always
fails and so is useless.
|
|
|
|
Following discussion in #7042, we write down an advice to give time
for last comments before merging potentially controversial PRs.
We document a practice that is becoming standard in order to improve
PR merging time: some other maintainer can self-assign if the main
maintainer is not responding.
Encourage component maintainers to announce when they won't be available.
We document the practice of code owner teams.
Co-authored-by: Hugo Herbelin <Hugo.Herbelin@inria.fr>
|
|
|
|
[ci skip]
|
|
We had mostly used absolute links in the past.
I just discovered that GitHub recommends using relative links instead:
https://help.github.com/articles/basic-writing-and-formatting-syntax/#relative-links
and indeed my Emacs Markdown mode can handle relative links but doesn't
interpret absolute links relatively to the root of the git repository.
[ci skip]
|
|
comments.
[ci skip]
|
|
Clarification prompted by Jim Fehrle.
[ci skip]
|
|
Simpler
|
|
Actually there are more general instructions
|
|
|
|
|
|
|
|
Including: how to create a GPG key.
|
|
In particular, describes what to do with overlays.
|
|
In particular, don't use the GitHub interface. Also, not all reviews are
mandatory in some corner cases.
|
|
We make GitHub assign only principal maintainers as reviewers. This
reduces the level of noise (PRs with 10 code owners), and makes it easy
for the assignee to check if all reviews have been completed (all
reviewers in the list have to approve the PR, which was not the case
before if two reviewers were assigned for the same component).
This change means that when a principal maintainer submits a patch
touching the component they own, they should ask a review from the
secondary maintainer.
|
|
|
