Instead of having a sid branch and putting new rc versions in master,
let's have the default branch, master, track sid, and put experimental
in a branch.

This is more likely to match what a random person looking at this repo
would expect by default.

home.md

@@ -13,8 +13,8 @@ Branches
 --------
 
 The repository has three types of branches:
-1. The `master` branch, which tracks the latest greatest upstream version.
-2. Branches to track different Debian releases (`sid`, `buster`,
+1. The `master` branch, which tracks the latest work for unstable (sid).
+2. Branches to track different Debian releases (`experimental`, `buster`,
    `buster-security`, etc).
 3. Team member branches, `<user>/*` (e.g. `knorrie/blaat-mekker`) are branches
    where team members can mess around, share ideas, share work for review etc.
@@ -22,16 +22,17 @@ The repository has three types of branches:
 When an upload is done, the release commit gets a signed tag with the debian
 version number.
 
-Note: Yes, this way of working is copied from the Debian Kernel Team. Have a
+Note: Yes, this way of working is copied from the Debian Kernel Team (except of
+using the master branch for tracking unstable instead of experimental. Have a
 look at [their git
 repository](https://salsa.debian.org/kernel-team/linux/branches) to see it in
 action with quite some history already.
 
 When a new upstream version is in release candidate stage, we can target Debian
 experimental for uploads to allow Debian users to help testing the new release.
-So even if for example Xen 4.10 is in unstable (getting updates in the `sid`
-branch), we can already work on getting 4.11 packaging in shape in the master
-branch.
+So even if for example Xen 4.10 is in unstable (getting updates in the `master`
+branch), we can already work on getting 4.11 packaging in shape in the
+`experimental` branch.
 
 Contributing
 ------------