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
signature.asc
Description: This is a digitally signed message part.
