# Before rc1
* Make sure who's doing PR and let Linus know ;-)
* Rebase dev branch onto the last PR (???)

# ASAP after rc1

Rebase dev branch (from vX-rc1 to vY-rc1) (new: `dev` branch process changes?)

dev branch option
* option 1: only use dev for PR.
*

1. Make sure vY-rc1 is out!
2. Push out the old dev branch (based on vX-rc1), say "dev-old"
3. Pour your favorite drinks ;-)
4. Rebase (or re-apply patches using quilt) onto vY-rc1, the result is
"dev-new", (Q: maybe take notes if there is any conflicts?)
5. Check no patch is lost via:
* gitk v6.10-rc1..
* tig v6.10-rc1..

git cherry -v dev-new dev-old

* [ ] (TODO: add <limit>)
* [ ] (TODO: try reverse case)

Look for result starting with "+" (Q: do we need to do this for any
future -dev branch?)

* [ ] (TODO: add range-diff)

* Double confirm with:

git diff dev-old dev-new -- <rcu related files>

(Q: we can actually calculate all the files touched by dev-old, so
maybe we can have a script generating all the "<rcu related files>")
6. Push out the dev branch (remember to use "--follow-tags" to also
push the tags)
* [ ] or "--tags"

# Around rc1 or rc2: Picking patches from dev to topic branch
* Make sure the dev branch (say "dev") is pushed out!
* Pour your favorite drinks ;-)
* Use `git cherry-pick`, `quilt` or whatever tools to create topic
branches.
* Do test for each topic branch!
* Do checkpatch for each topic branch!
* Make sure SoB or other tags are properly applied!
* See Documentation/process for full details.
* Pull requester needs to have their SoB (if the SHA1 gets changed)
(Q: anything else I'm missing?)
* Multi-merge topic branches into a PR candidate branch (which is also
for linux-next to fetch), say "merge-point"
* Check no patch is lost or newly introduced via:

git diff dev merge-point

(Q: how could we use `git cherry` here?)
* Another thing we can do to check missing patches is:
* `git range-diff <old> <new>`, "`<old>`" and "`<new>`" are ranges, and if they share the same common base, you could use "`<old>...<new>`"
* Push out the PR candidate branch (remember to use "--follow-tags" to
also push the tags)

# Before rc3: Sending PR review patches
* Make sure the PR candidate branch is pushed out!
* Generate a series for each topic branch, whose cover letter has the
title "XXX for vZ" ("vZ" is the kernel version where the PR will go
into, e.g. "v6.4")
* Check the series before sending, e.g:
* Use "--dry-run" of `git send-email` to check the Cc list and email
titles (and patch numbers)
* Won't hurt to run scripts/checkpatch.pl again.
(Q: what else?)
* Send out the patches! And job done ;-)

# Around rc7: Pull request time!
* (TODO: add examples)
* Make sure you have the pgp key to sign the tag
* Make sure all patches in the PR candidate branch have a Reviewed-by or Acked-by from relevant people.
* Create signed tag on the PR candidate branch:
* `git tag -s <tag name>`
* provide a summary of the PR in the tag message
* Use `git request-pull` to generate the content of `[GIT PULL]` email
* Example: `git request-pull v6.13-rc2 git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux.git rcu.release.v6.14`
* Add known any merge conflict resolution along with the reports of these conflicts (usually an email from linux-next)
* Send out the `[GIT PULL]` email

* urgent patch needs to go into the PR
* rebase topic branches.
* linux-next involvement.

---------------------
# Branches

* `next`: always pointing to the pull request candidate, will be fetched by `linux-next`.

* `dev`: a patch queue for potential patches for the next merge window, should also be based on `next`. At `-rc1`, a rebased (onto `-rc1`) `dev` becomes the new `next` at a starting point.
* This also means when the pull request duty is transferred from one and the other, the previous person needs to make sure `dev` contains all patches that need for the next merge window, especially when some patches show late in the development cycle, get accepted, but decided to postpone to the next merge window.

---------------------
* First bar: Use their own repository -> ask us to merge in next and rcu -> they send the PR

* Second bar: accessing the next branch of rcu repo

* requirements for accessing next branch
* have to finish a PR to Linus
* How to do that using rcu repo in kernel.org
* Need to have PR buddy <- The person who did the most recent PR with direct access to the rcu tree.
* expectation for PR buddy
* checking emails within 24 hour to handle any requests to merge in rcu's -next (should also pull tags as the tag will be in the PR email that they are sending).
* double check the PR before it is actually sent. (not limited to PR buddy, should be a group review)

* "two cylces" model
* "next" branch usage (rc7 vs pre rc7)
* topic branch