Hi Daniel,

please forgive me for brief, blunt, and perhaps somewhat irritated reply.


On Tuesday, 13 August 2024 9:34:54 PM AEST Daniel Gröber wrote:

https://salsa.debian.org/onlyjob/notes/-/wikis/bp

Yeah, that doesn't work for me. I get anxious without a git repo :)

In the end simplest and most straightforward approach works the best.

Use git repo, but don't rely on it to build a package.

You can build in dedicated build directory, and that don't have to be
the debian package repository.

Since I'm still searching here's my git workflow requirements list:

Overly complicated workflow is impediment for collaboration and
co-maintenance.

Simple is really the better. The less distraction on packaging tools will
give you more capacity to focus on problems that need solving.

- patches-applied (just commit/cherry-pick, no manual debian/patches handling)

There is no way to avoid manual handling of patches. Exporting git commit
as a patch is trivial enough. "quilt" may be not the most advanced
patch management system, but it is certainly quite robust.

- allows preserving upstream history

Get upstream history from upstream. More often than not you won't need
upstream history, and certainly there is no need to mirror it on debian infrastructure. It is most inconvenient when upstream history is
interleaved with debian package history. Keeping them apart is the best.

- "import" upstream releases from git

That is the most awful thing about GBP workflow. Sometimes it is not applicable, sometimes it does not work, when it works it works badly,
it comes with significant overhead plus risks of inconsistencies.
Many problems originate from storing upstream in debian packaging repo.

It is almost always redundant. As maintainer you have to make sure that "debian/watch" works and that tarball workflow works first. If that works
then importing upstream into packaging git repo is redundant.

I agree in principle but my solution does not involve giving up on git packaging tools entirely :)

Whatever works for you without adding complexity to your co-maintainers
is the best. I like "gbp dch --full" command -- perhaps the most (if not
the only) useful tool from git-buildpackage.

However: I think your criticism on space/bandwith use is unfounded. Git is spectacularly efficient at packing history. Even when it isn't because there's just so much of it --depth=N is always there to only download a compressed tarball's equivalent of data but with git benefits.

I'd also like to point out that git is more useful for bandwidth constraint users because it does delta-transfers. Imagine downloading multiple
versions of 0ad-data to do some archaeology.

Nonsense. It does not matter if instead of latest release you have to
download "well packed" history of all upstream releases ever packaged
in Debian. You should not have to do that when it is not necessary.

If you need archaeology then clone upstream repository, or download prior releases from Debian.

Bandwidth is not the only, or most important concern. When you work on many packages, repositories grow not only in space but also in numbers of files
and everything is getting slower. You'd notice when your repository grow to have around 100,000 files so you do slow and CPU-intensive "git gc --aggressive"
and doing that on many repositories is tedious.

Storing all upstream releases in "upstream" branch of packaging repository is unjustifiable, even if that became common/normalised packaging practice.

On small packages it is a little pain, but on large and complex packages it is a big pain, so big that certain packages can not be maintained in such manner.

IMO every workflow should have documentation like dgit's dgit-maint-* manpages even when it's "trivial". Any one workflow may be, but Debian has *many* of them.

Only something very uncommon needs to be documented within package itself.

For everything else there is plenty of information and general-purpose
approach to building packages is best to document elsewhere, outside of
package (e.g. in wiki).

Remember that everything committed is technical liability (debt) that
takes time to maintain.

Many prominent packages use it after all.

And many don't. So? Majority decision is rarely a most sensible one.

IMO if alternate workflows want to have any success they need
to be visible.

To whom? Isn't it a matter of attention? And sometimes it is a matter
of consensus or established practice within a team.

Complicated git workflows violate principle of least surprise.

--
All the best,
Dmitry Smirnov
GPG key : 4096R/52B6BBD953968D1B

---

Politics: the art of using euphemisms, lies, emotionalism and
fear-mongering to dupe average people into accepting — or even
demanding — their own enslavement.
-- Larken Rose

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

iQIzBAABCAAdFiEEULx8+TnSDCcqawZWUra72VOWjRsFAma7j6EACgkQUra72VOW jRtf9Q/+MkLRtWewiKsGVWom6UF1rqgLZnlfB0Bm+8OAxGUYijs8BkLoZB6wtMrE 4kVyHnWeMroA3ELIJYAe4Yi0vl5WlrlXV6WKdB3HRmG4pMeUePlBR3dgtT91+qEa FHwArmiBUG5eYmNTOzN6c0C7kdzo+8cd/Z98t2iMnoeJ/vYigXuOoMeC74NIEpQ3 PZudCXRNLSyhtZO0W6ojY6IyUsf4N0XfEvloDuKJEQ9f3HSsXFuWQVJzV0caOzuk sq4fOAqwKzEakcmv415+VPMFzlHJbHpGfZwXaQiOpfSj+hf+kbxkf7CZUkFYREfe P2ZFBsGAjpmWREoY6RZPlUFDWkuVF8vsQFgHe80BTbvN1o2O62l7/KUHXSejk2wE EZhn2yuTWZhu8EN6vQErroVNLbrXGtcalzYYxKpYPRp2mUP4VszDWDW+yUT2rXLm +JpReIa7bax7II72h7SyrbqxjVSaN7sE7udoExZJ15i7r94KiMh2M3c67pqftBIU aH9CmojgSk/OSkUYECqSwGglip0MGs5LTO3P4ekmrD2jtcPU4Q1/2UVxlWHmUZtz rykFdCJOm2vVsoTMVYoOzSquvId7IZBRdffVlSYhRYkYofuGAMys9kerQPEchCUF