site: process: Use a temporary branch for patch series.
We had both issues described in the text during the RC2: - Both maintainers agreed to merge a translation under a pseudonym but one of the maintainers also asked to GNU permission to do that. Due to a miscommunication between the maintainers it was pushed before getting feedback from the GNU project. - Both maintainers agreed to the release commit but due to a misunderstanding / miscommunication it was pushed too early while some other commits that still need to be made were supposed to go in before that announcement commit in order to tag that announcement. In both cases a process like the one mentioned in the text would probably avoid to push things too early, especially because the author of the patch set new about these issues and had them in mind all the time, and since an additional Ack from that person would still be needed before pushing, it would avoided this issue. Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> Acked-by: Adrien 'neox' Bourmault <neox@gnu.org>
This commit is contained in:
parent
a73a33fb17
commit
6f39a0011d
11
site/git.md
11
site/git.md
|
@ -191,6 +191,17 @@ like that:
|
|||
|
||||
in an (email) reply form the given maintainer.
|
||||
|
||||
The maintainers agreement on a patch doesn't necessary mean that there
|
||||
is an agreement on the order in which the patch will be added. So the
|
||||
patches can also land into a 'gnuboot-next' branch temporarily and
|
||||
potentially be re-ordered until all the GNU Boot maintainers agree to
|
||||
push all the commits in the chosen order into the main branch.
|
||||
|
||||
That 'gnuboot-next' branch can also be used when the GNU Boot
|
||||
maintainers agree to merge the patches but need to wait for the
|
||||
approval of the GNU project for instance if there are legal questions
|
||||
that also require the approval of the GNU Project.
|
||||
|
||||
Maintainers
|
||||
-----------
|
||||
|
||||
|
|
Loading…
Reference in New Issue