On Sat, Aug 16, 2014 at 1:59 PM, Raphael Hertzog <hert...@debian.org> wrote: > Hi, > > On Fri, 15 Aug 2014, Guido Günther wrote: >> The gbp manual has a recommended branch layout: >> >> >> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING >> >> which could serve as a basis. There's plenty of room for improvement, >> e.g. the case where one tracks upstream git isn't yet mentioned (I >> started to follow the above layout also in this case). > > Some comments on this recommended layout: > > 1/ I suggested <vendor>/master rather than <vendor>/unstable (or sid) > because it means we don't have to know the default codename/suite used > for packaging of new upstream versions (in particular for downstreams) > > 2/ having multiple upstream/<codename> is bound to never be up-to-date > when I do "git checkout debian/experimental && git merge > debian/master", upstream/experimental will get out of sync and I > won't notice it because my package builds just fine > > However multiple upstream/* branches can be useful, they should > just match real upstream branches... so things like upstream/master, > upstream/4.8.x, upstream/4.9.x, etc. > > 3/ I don't see the need for backports/<codename>, I would rather > use debian/wheezy-backports (which actually is just a specific case > of <vendor>/<codename> since wheezy-backports is the Codename in the > Release file) > and security/<codename> is just the continuation of <vendor>/<codename> > after a stable release, so again I don't see the need for a specific > branch here (and if we really need a separate branch, it can again > be <vendor>/<codename>-security)
I use for debian patches a debian-patches/version branch. Friendly upstream could cherry pick if they need it. Bastien >> > - 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) >> >> Agreed, although having a branch (and recommended naming convention) >> can be useful. > > Yes. > >> > - 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) >> >> The tag format is configurable in gbp and I'd expect downstreams to >> use a different name space (e.g. ubuntu/<version>). This makes it >> simpler to tab complete (or delete) certain groups of tags. A patch to >> make the tag message configurable too is waiting to be applied. pkg/ >> is too generic since we'll have more of the RPM support upstreamed >> soonish. > > Anything that needs to be configured is a source of error. I'd rather > have gbp do the right thing and pull the information from dpkg-vendor. > > 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/20140816115946.gd13...@x230-buxy.home.ouaza.com > -- 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/cae2spaypuva81apdlu1umwx0erog4ukwcihdxbzc37jzpet...@mail.gmail.com
