Quoting Luca Boccassi (2024-05-22 01:45:54)

On Wed, 22 May 2024 at 00:40, Russ Allbery <rra@debian.org> wrote:

For what it's worth, what I do for the packages for which I'm also
upstream is that I just add Salsa as another remote and, after I upload
a new version of the Debian package, I push to Salsa as well (yes, including all the upstream branches; why not, the Debian branches are
based on that anyway, so it's not much more space). One of these days
I'll get CI set up properly, and then it will be worthwhile to push to Salsa *before* I upload the package and let it do some additional
checking.

It's still an additional step, and I still sometimes forget to do it, but after some one-time setup, it's a fairly trivial amount of work.

It's more work to accept a merge request on Salsa and update the repositories appropriately, since there are two repositories in play, but in that case I'm getting a contribution out of it that I might not have gotten otherwise, so to me that seems worth it.

I used to try to keep the debian directory in a separate repository or try to keep the Debian Git branches in a separate repository, and all of that was just annoying and tedious and didn't feel like it accomplished much. Just pushing the same branches everywhere is easy and seems to accomplish the same thing.

Yeah I am doing the same, and gradually switching all my packages that
used to have a separate upstream/downstream history to a single merged
tree. This can be done post-facto with some one-time git rocket
surgery, doesn't have to be the case from day one. It's a huge
improvement, and with gpp patch-queue I can just cherry-pick upstream
commits directly, with no hassle whatsoever. It works really nicely,
and gbp supports it just fine as a workflow, even while still checking
in upstream release tarballs in pristine-tar.

I would be *very* interested in more in-depth write-ups of the workflows other DDs prefer to use, how they use them and what they think makes them better than the alternatives.

Personally, I start packaging something without git, once I'm satisfied I use "gbp import-dsc" to create a packaging git with pristine-tar (and that will *not* have DEP14 branches and it will use "master" instead of "main") and then I push that to salsa and do more fixes until the pipeline succeeds and lintian is happy. My patches are managed using quilt in d/patches and upstream git is not part of my packaging git. I upload using "dgit --quilt=gbp push-source".

Would another workflow make me more happy? Probably! But how would I get to know them or get convinced that they are better? Maybe I'm missing out on existing write-ups or video recordings which explain how others do their packaging and why it is superior?

Any hints or future debconf workshop invitations welcome. :)

Thanks!

cheers, josch
--==============536370389304303352=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmZNfh0ACgkQ8sulx4+9 g+HTcBAAtr5h+lu8CRxIjSI+u/k5FuTj/nZFDyIX5xIeYHZcyRQ8YVkdB50fGjpl dB7sGcWPBrEyhXxZjib+yfDK1hvOPi+bnWgWle1GTdNv5cYi1V5OW8BSmYzEcKr7 Ag0I3EDHF4j37gA+fQj/Mo7nNwUCIthBy9xjIbuYcnSvM7SM5kkCfXd07YCxyoH4 xq8WHI7h21jqZs0thsUQpginzygxDizYWmoFAzIgkv5XhSUj7qTAsEgAGK5hJ2L7 W9xvezYMvVeLD2/qHeOAPQuNVyDa4xf+VHyRXxen8SNeHTggDd0NtryUQNiDCQBM X+3gyAeTnxEr6lDMgZklZFVwew6tZI5fKzZMCpLjU3z7M18DIKLgkXICWF+Mnf9G 103duIPy6axejtjP6fd0TEkf+4f21ZtCJZOuXQ3Qy0KUcsKeTrVtaydFEevP2nvu WZooIG0dEoNTWs++Bv4tn5SawfP15mgyybNsVyce6DTYwtwncAxOj3Y4jQPsRsQY 6f+b84KpYwpe/U5vMjDz3JEbZlzMs6XONaNa4zxVZijAJ9TZixJwDhs8DMaQ3JIk mYzdBmCnRof9Voq91jAB6gDfIj4ql9Zalry7/rmy+kZgYYzUwNuqjVa2CSqUQYkj yNrW9xeACtZvO5plGUow9r93xb4HohqcC+R2GbnmGd7uLjqTnsg=
=N/od
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

My standard workflow

I use gbp and dgit

gbp import-orig --pristine-tar --uscan
gbp dch
lintian-brush
dgit --gbp sbuild (build and autopkgtest)
...work until it is ok on my computer
gbp dch
... hand edit the changelog
gbp push
git push (to push the UNRELEASE master branch)
... wait for salsa result if everythings is ok
... if not work and push commits to salsa
... then relase with
dch -r
dgit --gbp build-source
dgit --gbp push-source
gbp push


I like the way dgit help for the upload.

Cheers

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Johannes Schauer Marin Rodrigues <josch@debian.org> writes:

I would be *very* interested in more in-depth write-ups of the workflows other DDs prefer to use, how they use them and what they think makes
them better than the alternatives.

Personally, I start packaging something without git, once I'm satisfied
I use "gbp import-dsc" to create a packaging git with pristine-tar (and
that will *not* have DEP14 branches and it will use "master" instead of "main") and then I push that to salsa and do more fixes until the
pipeline succeeds and lintian is happy. My patches are managed using
quilt in d/patches and upstream git is not part of my packaging git. I
upload using "dgit --quilt=gbp push-source".

Would another workflow make me more happy? Probably! But how would I get
to know them or get convinced that they are better? Maybe I'm missing
out on existing write-ups or video recordings which explain how others
do their packaging and why it is superior?

One of the lesser-known things found in the dgit package is a set of man
pages describing several packaging workflows. These certainly aren't exhaustive of the packaging workflows that people use (for one thing, they
are designed to explain how to use dgit in each workflow, and thus of
course assume that you want to do that), but they're both succinct and
fairly thorough and I found reading them very helpful. dgit(1) has a list
at the start.

dgit-maint-debrebase(7) is the workflow that I now use, pretty much
exactly as described. The primary thing that I like about it is that I
never have to deal with the externalized patches or with quilt (I used
quilt for years, and I have developed a real dislike for it and its odd
quirks -- I would rather only deal with Git's odd quirks), and I can use a git-rebase-like command in much the same way that I use it routinely for feature branches when doing upstream development. Then some Git magic
happens behind the scenes to make this safe, and while I don't understand
the details, it has always worked fine, so I don't really care how it
works. :)

I like having a Git history from as early in the process as possible and I
want the upstream Git history to refer to while I work on packaging (and
want to be able to cherry-pick upstream commits), so I generally start
with a tagged release from the upstream Git repository, create a branch
based on it, and start writing and committing debian/* files.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I would be *very* interested in more in-depth write-ups of the workflows other DDs prefer to use, how they use them and what they think makes them better than the alternatives.

Packages of which I am not the creator:

salsa project and gbp

UNLESS they are qt/kde stuff

in which case

salsa project and debian/ directory kept on salsa, because that's how the team does it.

Packages of which I am the creator:

debian/ directory kept in the same tree as the rest of the project, then a Makefile to pretend that they are separate entities, that generates a .orig and then builds the whole thing extrating the .orig and placing the debin/ directory appropriately.

It is for this case that I would be annoyed by having to use salsa. Because
the projects are not on salsa to begin with.

I'm also annoyed at the default ci configuration for salsa, because importing a project makes a CI start to run, then fail. Then I have to one by one point
the CI file to something else, but the project will forever be "CI failing" and will be reported forever as such in my status page.

--
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.codeberg.page/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Salvo Tomaselli <tiposchi@tiscali.it> writes:

I'm also annoyed at the default ci configuration for salsa, because importing a
project makes a CI start to run, then fail. Then I have to one by one point the CI file to something else, but the project will forever be "CI failing" and
will be reported forever as such in my status page.

If you go to the individual pipeline that you never wanted to run (e.g.
click on the red 'X' in the overview, or the pipelines view), then
you'll see a 'Delete' button in the top-right corner.

If you delete all the pipelines in a repo, it reverts to thinking CI is
not setup, and you'll no longer be told that the repo is 'CI failing'.

BTW I just confirmed that by setting up a new repo for the purpose, and
was surprised to find that I also needed to configure CI in order to get
it to fail, so I think you may be right that it was once doing the
annoying thing you describe, but it didn't do it to me just now.

HTH

Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmZN8WYACgkQ0EujoAEl 1cCuEQ//SF5QK4BYe7wM6DN+NLizvphlYxC/Y7hgVXSEk/U3WnW0p2DGkw5/iHuo KitAHVK6TaXRq95Rjo1dKCEIwrVeX1/9v1wZBgNB2dwJkc3js/z9IG9hJ9jM3rH2 QAguSQf67biV0l5Igc5xeVuK1ucsV6KlE3zcxePXSVnx9CQh83VjweDk9uGVuQfA LA72hmOjQRhxm3jum9RyqXFHhHXu4QWYkgna3KI2v0DdWp2IXUL9kAebkxJoJ4yY r6vZYcVS6Yj28uBHHq79JiqY3M/joyGi/ZCw+1sfjdtj1b23o0YBS8MBTRuxKFqw SSds9SXvAOtc3UsjB4htp7SNJNsEx6vltzvsHlrY4P/1n/Te0Kprfwiby9unAPs2 IRvAvjUQtFUb8tuSngUzOupOV88/mBOJHnj50TWW1PON1PuSV/AliIsDsuLIKzu0 07MIsmF8B8s0aB9T/jZn55Ab8CaDOCuh1dVKD/vnrvoJ/9S4B3X4KC1a+/Tcl6QW YWTTyeMhBQe2YvXI8Uqzlks0P4cbed8GOQCXxORF9lfpbmQHMV/QpTvr5or7Za6q MOypU4kAyh1E/DWKdJjipRNoLNr5eTcuayT+Cy3iW4C+oo93O16kh6iEIjuW1W1g umMmDDreXttk0V1Arkq4pEU6JctHgqR3ZxlASxLb30ZWh4rcwT0=U9qW
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gatewa