Re: Standardizing the layout of git packaging repositories
On Sat, Aug 16, 2014 at 1:59 PM, Raphael Hertzog <hertzog@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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 20140816115946.GD13596@x230-buxy.home.ouaza.com">https://lists.debian.org/[🔎] 20140816115946.GD13596@x230-buxy.home.ouaza.com
>
Reply to: