Hi Thomas, On Sat, 16 Aug 2014, Thomas Goirand wrote: > > 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). > > I generally use debian/unstable, but sometimes, it's best to follow > upstream (for OpenStack, I use debian/icehouse, debian/juno, etc.), so > there's no one-size-fit-all here.
Branches are cheap so you can easily have both if the upstream-based branches bring you value. But it's disconcerting for random Debian contributors to not have a clear mapping with Debian 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) > > Why would you tag the upstream release? I mean, it's upstream's job to > do so, and it's natural to use their git tagging and their git > repository, no? Ideally, yes, but: - not all upstreams use git (and in those case we want to create our own tags pointing to synthetic commits created by tools like gbp import-orig) - among upstream using git, some are not creating proper tags/releases (and we are doing releases based on snapshot tarballs where we are creating our own version like "0~20140812") - among upstream who are creating tags, there's no single naming convention that is shared (and it can be useful to duplicate the upstream tags in a namespace of our own) Obviously, when upstream are already doing everything correctly, creating the upstream/<version> tag should not become some administrative chore but it could be done automatically as part of a some "gbp upstream-merge <upstream-tag>" command for example. > > - where should the HEAD point to in the public repository? > > IMO, it should point to the packaging branch for Sid, but YMMV. Why is > this important? It's the default branch one gets when you do "git clone", it's better if the user ends up on some useful branch. I agree with you, it should probably be <vendor>/master (assuming we keep that branch naming). > > - 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? > > Sorry, which layout are you talking about? With pristine-tar? Well, I > don't think using pristine-tar is in any way "traditional", it's just > one of the workflow, which I always avoid if upstream is using Git and > has correct tagging. This question had nothing to do with pristine-tar. It's just that if you look at the dpkg repository, we are doing upstream development in Debian and are thus using the master branch directly (and it would not make sense for us to start using debian/master). Similarly, since we are also upstream, it would not make much sense for us to create upstream/<version> tags... Hence the question of how to adapt the conventions for this specific case. > > - are there other important things to standardize? > > Yes. Producing orig.tar.xz out of upstream tag should be industrialized, > and written in "some" tools, which we would all be using. I currently > do: ./debian/rules gen-orig-xz, but that shouldn't be specific to my own > packages. Elsewhere you seem to imply that "git archive" should be enough. So what is there to industrialize here? That said I don't believe that this DEP should mandate anything on the tarball to use (i.e. upstream provided tarballs vs something generated with git archive). 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/20140816191315.gi13...@x230-buxy.home.ouaza.com
