Re: Survey results: git packaging practices / repository format
On Mon, 01 Jul 2019 at 07:30:39 +0200, Andreas Tille wrote:
> I admit I did not joined the dgit discussion - may be that's the reason
> I can not really match the branches that are used in Perl team policy
>
> https://perl-team.pages.debian.net/git.html#repository_layout
>
> (which is used by several other teams I'm working in) to the table in
> the Wiki.
The precise names of the branches are not immediately relevant to
GitPackagingSurvey: it's the content of those branches that matters.
>From https://perl-team.pages.debian.net/git.html#Patches it appears
the Perl team is using what the survey page has labelled as "unapplied"
(also seen referred to as "patches-unapplied" elsewhere):
- a git checkout of the packaging branch contains debian/control, etc.
- a git checkout of the packaging branch contains upstream files like
Makefile.PL
- if the Debian maintainer has patched upstream files like Makefile.PL,
those changes appear as a quilt-style patch series in debian/patches/*
- if the Debian maintainer has patched upstream files like Makefile.PL,
those changes are *not* reflected in the copy of Makefile.PL you get
by just checking out the packaging branch (hence "unapplied" - in the
representation you check out, your patches exist as patches but have
not been applied yet)
(If you read those and you think "well, obviously... what else would
we do?" then you probably haven't encountered the workflows represented
by the other rows in the survey's table.)
This is the same setup that gbp-pq assumes, and is also used by the
GNOME, systemd and Python modules teams, among others, although with some
variation in branch naming. The main variation that I've seen is that
some teams (e.g. Perl) consistently use the default gbp branch names,
some teams (e.g. GNOME) consistently use the names recommended in DEP-14
<https://dep-team.pages.debian.net/deps/dep14/>, and some teams vary
per-repository (e.g. games, Python modules).
default gbp branch name DEP-14 branch name
(e.g. Perl and systemd teams) (e.g. GNOME team)
----------------------------------- ------------------
master debian/master
stretch, etc. (not standardized) debian/stretch, etc.
upstream upstream/latest, upstream/2.32.x, etc.
pristine-tar pristine-tar
I personally think DEP-14 is a good idea, and I advocated its use when
the GNOME team switched from svn to git. It's particularly useful when
more than one upstream branch is packaged in parallel (for example GNOME
3.30 in unstable and 3.32 in experimental at the moment), or when there
is an active downstream distro, which can simply branch from the Debian
packaging and replace debian/ with their own name (for example Ubuntu
uses branches like ubuntu/cosmic for automated package source imports
on Launchpad, and various smaller Debian derivatives like Apertis,
Kali Linux and SteamOS use DEP-14 branch names like apertis/v2019,
kali/master and steamos/brewmaster to track their modified packages).
smcv
Reply to: