Differences between revisions 2 and 3
Revision 2 as of 2017-11-21 09:41:07
Size: 2219
Editor: ?OttoKekalainen
Comment:
Revision 3 as of 2021-09-15 05:07:19
Size: 2342
Editor: ?OttoKekalainen
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
----
'''See new wiki page at https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/MariaDB-in-Debian'''
----


See new wiki page at https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/MariaDB-in-Debian


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

Tags:

  • 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

Important practices:

  • 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>