We should default to branch layout that uses debian/sid as default
packaging branch and upstream/latest for the upstream sources when
creating new repositories with import-dsc or import-orig.

Hi,

Thanks for the reminder. Defaulting to `debian/master` should
certainly be flipped for bullseye (and that one is easy where switching
from upstream to upsteam/latest is harder) since if the branch exists it
can't easily become a directory).
Cheers,
 -- Guido

Hello,

DEP-14 has seen a final change where we now recommend debian/latest
instead of debian/master:
https://dep-team.pages.debian.net/deps/dep14/

It would also be nice if the default of the branches and tags could rely
on a "%(vendor)s" substitution and if that vendor value could be easily
overriden in debian/gbp.conf without having to override the branch and
tag names.

Nice to see that you want to see this done for bullseye but the freeze is
approaching quickly so we should move on if we want to see this happen.

Cheers,

Hello!

Any updates on the Debian package git branch layout?

I am about to start working on mariadb-10.6 and will create a new repo
for it, and would be open to adopting DEP-14 if it is finalized.

If gbp-buildpackage adopts the current  DEP-14, please mention it in
the changelog:
https://tracker.debian.org/media/packages/g/git-buildpackage/changelog-0.9.23

Latest reference to DEP-14 is in 2016. Following DEP-14 would be
easiest if git-buildpackage simply did so by default.

Also, it would be nice to see a couple of links to repositories that
have DEP-14. Even better would be some stats on the different
suggested conventions to see what their adoption rate currently is,
and what has turned out to be the most popular conventions.

Thanks if you have time to update the status on this,

- Otto

Hi Otto,

It mostly didn't happen due to lack of time. Hope to make some progress
at next mini debconf but will also happily review changes.
Cheers,
 -- Guido

I finally got around to doing MariaDB 10.6 for Debian. In the same
process (as I was about to make a new repo anyway) I migrated the old
mariadb-10.5 to the debian/latest branch structure and then build
mariadb-10.6 on top of it. Everything worked well when I just
remembered to override the git-buildpackage defaults.

Hopefully you Guido have time in the future to update
git-buildpackage, it is absolutely the foundation of all my Debian
packaging work :)

Also related, you might want to update
https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html
by running 'sed s|debian/sid|debian/latest|g' on it so it also follows
the latest DEP-14.

Thanks!

Hi and Happy New Year!

Using 'debian/latest' instead of 'master' by default in
git-buildpackage would still make sense.

I started drafting a PR at
https://github.com/agx/git-buildpackage/pull/93 to implement this, but
it takes a while to read through and understand all the 500+ mentions
of string 'master' and which of these refer to default Debian branch
and which not.

I have been using the debian/latest convention from DEP-14[1] in all
my packages for several years now. This is the scheme I follow based
on what I find most practical:

- debian/latest
- debian/12-bookworm
- debian/11-bullseye
- debian/11-bullseye-backports
- debian/10-buster
- ubuntu/23.10-mantis
- ubuntu/22.04-focal

Having the release number in addition to to code name makes it easier
for contributors to choose the correct branch for Merge Requests, and
also ensures they are nicely sorted in chronological order in branch
listings.

The upstream branch name is whatever upstream uses (typically master,
main or a version branch or tag, e.g. 10.11 or 5.5).

For reference these are the gbp.conf changes I use for maintenance branches:

± git diff debian/latest..ubuntu/23.10-mantic debian/gbp.conf
diff --git a/debian/gbp.conf b/debian/gbp.conf
index c82f832717a..bfdfe73742c 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -8,7 +8,9 @@ sign-tags = True
 upstream-signatures = on

 # DEP-14 format
-debian-branch = debian/latest
+debian-branch = ubuntu/23.10-mantic
+debian-tag = ubuntu/%(version)s
+debian-tag-msg = %(pkg)s Ubuntu release %(version)s
 upstream-branch = 10.11
 upstream-tag = mariadb-%(version)s

The proposal by Raphaël to support %(vendor) would help automate the
debian-tag and debian-tag-msg so they don't need to be customized per
branch.


[1] https://dep-team.pages.debian.net/deps/dep14/

Hi,

It does. Thanks for looking into this. I'll add some details below:

I'd prefer (as noted above) "upstream/latest" as the new default here as
that has less potential to cause havoc.

What we need to figure out is a way to distinguish "old" style
repos (default upstream and master (or what gbp.conf provides) with
newly created ones (default debian/latest and upstream/latest or what
gbp.conf provides).

Likely the best way to do so is to add a `gbp.conf` option:

`layout = [legacy|dep14]`

defaulting to `legacy` if unset.  We can then emit a warning and
deprecate the legacy layout when `layout` is unset and any of
`upstream-branch`, `debian-branch` is unset. We can also back that up
with tests. At a later point we can switch the default.

A related issue is interoperability between different gbp versions but
when collaborating in a team but I think we can at least manage to not
break anything when the new defaults don't overlap with the old ones
(this would be o.k for {debian,upstream}/latest).

Cheers,
 -- Guido

Thanks Guido of for the inside about backwards compatibility issues. I did
not realize that git-buildpackage doesn't have way did is distinguish when
it is running on an existing repository and when on a 'fresh' repository.

Maybe we can engineer something to give it that capability automatically,
without any new 'layout' config flags?

Following DEP14 is just an aesthetic issue - I'd prefer to not have it if
the cost is that some existing repositories need a manual gbp.conf update
to continue to build down the road.

Another possibility would be to check which branch exist and understand
what is the intended layout. debian-janitor does that.

Pseudo-code:

if branches.include?("debian/latest", "upstream/latest"):
     layout = dep14-2020
if branches.include?("debian/master"):
     layout = dep14-2014
else:
     layout = legacy

Obviously this must be tweaked to take into account branch names set via
gbp.conf.

Regards,

Hi,

considering that it makes sense to settle with DEP14[1] first before we
can decide about DEP18 I wonder what is finally needed to accept DEP14.
I think its cruxial to make git-buildpackage supporting DEP14 per
default[3] but I'm somehow sensing some hen-egg problem here what to do
first.  If DEP14 might be accepted the motivation to fix bug #829444
would be probably way higher.

Just a personal note: All repositories where I'm uploader (>1000) are
following git-buildpackage default layout and thus not compatible with
the DEP.  So accepting DEP14 would mean a lot of work for me (at least
testing the suggested scripting solutions[4] carefully) and for my
personal workflow I'm not really keen on pushing DEP14.  However,
wearing my DPL hat with the clear intention to streamline common
workflows, I'd be happy if we would move forward here.

Are there any blockers to accept this DEP which I might have missed?

Kind regards
    Andreas.

[1] https://dep-team.pages.debian.net/deps/dep14/
[2] https://salsa.debian.org/dep-team/deps/-/merge_requests/8
[3] https://bugs.debian.org/829444
[4] https://lists.debian.org/debian-devel/2020/09/msg00168.html
https://lists.debian.org/debian-devel/2020/09/msg00172.html

Yes to finalizing DEP-14 soon, but first I think we need to complete the
technical work to have git-buildpackage use DEP-14 branch names by default.
I tried implementing it but turned out a bit too involved..


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444
Use DEP14 branch layout by default
= master -> debian/latest
= upstream -> upstream/latest

Any hands available to help with this?

Hi! I use git-buildpackage for my Debian work. But I think is not
necessary have git-buildpackage compatible with DEP-14 before, is it?

Hi Otto,

Am Thu, Aug 15, 2024 at 01:43:40PM -0700 schrieb Otto Kekäläinen:

Well, this is what I meant as a hen-egg-problem.  It might support
DEP-14 since it would be way easier to follow the DEP using the
well-known and really convenient tool.  However, it might be that
Guido (in CC) is more motivated to adapt the tool to a DEP once its
accepted.  Guido, what do you think?

Perhaps this should rather be discussed in the bug log.

As far as there are no concerns about DEP-14 any more it might make
sense to do this.

Kind regards
    Andreas.

Hi,

It's never been a lack of motivation (I use DEP-14 in about all
projects). More a lack of time to figure out a proper migration path.

Cheers,
 -- Guido

Hi all,

In #829444 it has been proposed the addition of a new "layout" option to
gbp.conf, which would tell git-buildpackage which layout to follow,
allowing for a graceful migration.

I've been thinking about a different approach though. What about adding
a warning to git-buildpackage when `debian-branch` and `upstream-branch`
are not set in gbp.conf? Compared to the `layout` option, it would have
the following benefits:

- People already following DEP-14 don't have to do anything (big benefit
  in my opinion)
- It would (probably) be easier to implement in gbp

I also see the follwing cons:

- We'd have to hardcode "debian/latest" and "upstream/latest"
  everywhere, which isn't pretty
- Maintainers may be less prone to change branch names since having
  `debian-branch = master` doesn't look as bad as having `layout
  = legacy`

After giving enough time to people to fix the warning (either by
switching to DEP-14 or by keep using their own custom branch names for
whatever reason), git-buildpackage can be switched to use DEP-14 branch
names by default.

How does it sound to you? Am I missing something?

Bye!

Hi,

Am Fri, Aug 16, 2024 at 11:09:58AM +0200 schrieb Andrea Pappacoda:

I prefer having no debian/gbp.conf at all in case the repository layout
would fit team policy.  So the question is whether git-buildpackage can
cope with the old

   master + upstream + pristine-tar
as well as
   debian/latest + upstream/latest  + pristine-tar

if no gbp.conf exists.

Kind regards
    Andreas.

    Andreas> Are there any blockers to accept this DEP which I might
    Andreas> have missed?

Honestly, the git-buildpackage default layout is good enough, and dep-14
 involves change  that doesn't feel like it brings enough value to me.

I.E. I think that dep-14 has been around so long and hasn't gotten
accepted is a strong suggestion that it doesn't bring sufficient value.
And I think that alone is a blocker.