Hi Anthony,
Thanks for quick reply.
On Monday, 24 February 2020 3:37:40 PM AEDT Anthony Fok wrote:
> add the "-dep14=false" flag to keep using "master" as debian-branch.
> "dh-make-golang make -help" for details.
This is handy. Noted. Thanks.
> The default of "debian/sid" is proposed in DEP-14, see and
> https://dep-team.pages.debian.net/deps/dep14/
Yes I am aware of the proposal and I am _strongly_ against it.
IMHO DEP-14 achieves nothing yet implies a lot of extra work for no
justifiable benefits.
Default git branch "master" is a perfect fit for default upload suite.
Changing default branch is _disruptive_ as it requires to reconfigure
repositories on Salsa, change repository layouts of _all clones_ as well as
to influence habits, let alone to incorporate new configuration to
"gbp.conf".
So far I've seen DEP-14 changes on numerous repositories and every time
adjusting to it is a waste of time, frustration and inconvenience.
I'd much rather invest time to do the actual work.
> Over the past couple years, I myself have slowly come to accept that
> "debian/sid" as the new default debian-branch for the following
> reasons:
Thanks for sharing your reasons. It does provide an interesting insights into
accommodation of DEP-14.
> 1. "master" may often mean the upstream master branch.
> One needs to take extra steps such as checking for the presence
> of debian/* or viewing git log to make sure it is indeed a Debian
> branch and not the upstream master.
IMHO the expectation of Debian (not upstream) repository is always to have
the actual "debian/" directory. DEP-14 improves nothing here.
> 2. "debian/sid" explicitly spells "Debian", the "sid" or
> unstable/development branch. No ambiguity.
Like it was ever a problem? Often unspoken convention is to name other
branches after intended suite (e.g. "buster-backports", "experimental").
> 3. "debian/sid" naming fits well with branches for backports, e.g.
> "debian/buster-backports"
Frankly I don't recognise any improvements here.
> 4. A few developers (Martina, and perhaps Tincho too? My memory is
> vague) started converting some repos from master to debian/sid, and
> recently, I have joined that rank, as in I have a bsah script that
> automatically converts master to debian/sid and updates the default
> branch on Salsa, almost whenever I touch an existing package (usually
> in fulfillment of hugo's build dependencies.)
I've found it highly to be inconvenient. To me conversion of repositories
layout to DEP-14 violates principle of least surprise. I can tolerate the new
layout for new packages but changing existing layout for no good reason is
not helpful.
Please don't alter layout of repositories where I am actively working.
> I have some of my own attachments too, e.g. I think pristine-tar
> branch can be kept even in the new workflow: pristine-tar may have
> issue with XZ-compressed tarball, but it is often fine for
> GZIP-compressed tarballs, which is the case for unpacked upstream
> release tarballs provided by GitHub, which probably applies to a
> majority of the package nowadays. And that's why the packager may
> choose to run dh-make-golang with "-pristine-tar=true" to let
> dh-make-golang create the pristine-tar branch as before.
IMHO "pristine-tar" branches are redundant. `origtargz` always fetches the
correct tarball from Debian mirrors network for already uploaded packages and
falls back nicely to `uscan` whenever new tarball is needed.
> By the way, thank you very much for fixing problems that I created in
> several of Go packages! Very much appreciated!
Thank yo for your kind words but I don't recall fixing anything like what you
are thanking me for. :) I guess that just how good team work should feel
like. :)
Thank you for all your hard work as well.
--
Cheers,
Dmitry Smirnov.
---
No person, no idea, and no religion deserves to be illegal to insult,
not even the Church of Emacs.
-- Richard Stallman
Attachment:
signature.asc
Description: This is a digitally signed message part.