Hello,
while git is the most popular VCS for packaging, there's no clear rules
on what you can expect in a random git packaging repository listed
in Vcs-Git. I would like to fix this so that:
- we can extract more useful data from the git repositories
- we can more easily share our git repositories with upstreams
and downstreams
- we start to converge on some conventions even though we might
continue to use different git helper tools
I want to use the DEP process for this. But before I can write a first
draft I would like to have your ideas of what we should include
in such a document.
Some initial questions and possible answers:
- how do we name the various branches?
- <vendor>/master for the main development trunk (aka unstable in Debian)
- <vendor>/<codename> for alternate versions
The goal here is to be able to host in the same repository the branches for
multiple cooperating distributions (at least so that downstream can
clone the debian respository and inject their branches next to the
debian branches).
- how do we tag the upstream releases?
- upstream/<version>
(note: we don't need an "upstream" branch, having the good tag for any
release that the distros are packaging is enough, it can point to a
synthetic commit built with tools like git-import-orig or to a real
upstream commit)
- how do we tag the package releases?
- pkg/<version>
(note: git-buildpackage uses debian/<version> but I find this confusing
as we then also have the "debian/" prefix for ubuntu or kali uploads, we
don't need the vendor prefix as the usual versioning rules embed the
downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
any conflict on the namespace, keeping a prefix is important to easily
differentiate tags created by upstream developers from tags created
by packagers)
- where should the HEAD point to in the public repository?
- shall we standardize the "pristine-tar" branch?
- the above layout is for the traditional case of non-native packages,
what would be the layout for native packages? how can be differentiate
between native/non-native layout?
- <version> encoding (due to git restrictions):
":" -> "%"
"~" -> "_"
- are there other important things to standardize?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140815141601.ga11...@x230-buxy.home.ouaza.com
