To keep the barrier of contributions as low as possible, the packages' git repository layout, branches and related practices should be documented and as clear as possible.
Current authoritative repository locations of MariaDB versions published in Debian (and Ubuntu):
All of the above follow this branch layout:
upstream includes each upstream release, one commit per tar.gz published by upstream
pristine-tar includes the binary diff so the upstream tar.gz packages can be reconstructed
master contains the development head, from which uploads to Debian unstable or experimental are made
when a Debian or Ubuntu release is made, master is branched into a release branch, eg jessie or ubuntu-16.04
- in addition, there can be separate feature or bugfix branches like in any software project
each uploaded commit is tagged with distro/release, e.g. ubuntu/5.5.57-1ubuntu0.14.04.1 or debian/10.0.32-1
- in addition there are the git-buildpackage automatically generated tags
The master branch always contains the history of the MariaDB packaging in Debian as far as history can go. So when running git blame debian/rules in the mariadb-10.1.git repo you can see all history from the beginning of time e.g. when mariadb-5.5 was introduced into Debian).
- When a new upstream major release is available, the old mariadb-x.x repo is copied into a new mariadb-x.y repo. This way there is less need for manual work (and errors) as copying the whole repo into a new repo copies all old branches (master, upstream etc) and the repo name itself separates the branch namespace from all other branches. The repository for the latest upstream major release is easy to keep clean from excess branches.
If a commit for some reason needs to be cherry-picked from a branch in an older major release repo, it can be imported git git-patch or merged via git pull ssh://git... <commit id>