[pkg-go] Bug#1105153: Bug#1105153: gocryptfs: Salsa CI is failing

[Dmitry Smirnov]

Hi Otto,

On Wednesday, 14 May 2025 4:24:02 AM AEST Otto Kekäläinen wrote:
> While I disagree on what is an optimal workflow, I appreciate that you
> have documented at https://salsa.debian.org/onlyjob/notes/-/wikis/home
> your workflow, and what your experience was with the other tools and
> the issues you ran into. A lot of people just state their opinions
> without detailing what problem they exactly ran into, nor presenting
> what their alternative solution is.

Thanks. Though I wish you had a little more faith in my experience... ;)

I have more unwritten material on the subject, like cases where GBP is
not merely suboptimal but outright inappropriate, harmful, or impossible
(or at prohibitively difficult) to use.


> Perhaps one day I will do a writeup that explains how to efficiently
> use `git reset --hard` in the gbp context, how to use `git difftool`
> to view differences between upstream/Debian or various Debian releases
> in Meld, and in general how to use gbp now in 2025. I think that one
> of the biggest shortcomings in git-buildpackage has been that the
> documentation historically has only listed options on what is
> possible, without actually listing the exact commands Debian
> maintainers should be repeatedly using in dally work to review package
> history, prepare new upstream imports, submit Merge Requests,
> efficiently git amend and rebase, force push new versions for
> re-review, how to efficiently prepare stable and oldstable updates in
> parallel without duplicating work etc.

It would be great if you do such writeup, but IMHO it is actually a part
of the problem: GBP workflow is so sophisticated that it requires much
experience as well as esoteric knowledge -- all that is especially
difficult for newcomers as it wastes a lot of effort for little benefit
even as convention.

And even without some advanced git skills, GBP workflow can be grinding
and tedious, like when you repeat commit-ammend steps many times when
testing and staging changes, instead of committing finished work once
when it is done.


> We have ventured quite clearly outside a regular bug report
> discussion, so I will end here. Just to clarify: I am not doing any
> changes to the gocryptfs package or repository, and nobody is planning
> to remove the origtargz fallback in Salsa CI. I am just saying that
> this repo layout is not ideal in my view, and I would feel severely
> limited if I had to maintain a package without access to upstream
> source in-place or upstream git history.

Indeed. As my closing comment I just want to add that if you think that
"upstream source in-place or upstream git history" are useful then they
are, and you should have them at your convenience as local branches.

As for myself, I tend to have a fork of upstream github project with
"upstream" branch following upstream repository as a _separate_ repo.
I do not want to have one repository tracking my github fork, upsteam
repo, and Salsa packaging all in one repository. 
Also, merging upstream history with history of Debian packaging is
harmful because packaging and upstream development are distinctly
different tasks.

I hope at least some of that makes sense.
Thank you for your help and attention.

-- 
Kind regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

The greater the state, the more wrong and cruel its patriotism, and the
greater is the sum of suffering upon which its power is founded.
 -- Leo Tolstoy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20250514/5e2ee49d/attachment.sig>