Hi Simon, On Mon, Jul 01, 2019 at 11:09:27AM +0100, Simon McVittie wrote: > 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.)
I confirm that your assumptions about the Perl team (and many other teams) are correct and I have now understood your table better. > 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 That's also correct. BTW, I see room for unification here to settle with a common branch name layout. > 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). I admit under the circumstances you describe DEP-14 has advantages over default gbp. I'm not sure how productive it would be for teams with about 1000 packages to change the repository layout (posssibly its scriptable) just to reach more inter-team uniformity. I personally considered a good idea to stick to gbp default. In case gbp might change that default I'd consider to follow that change. Kind regards Andreas. -- http://fam-tille.de
