Hi, 在 2024/6/18 18:07, Paride Legovini 写道:
The upstream branch is used on most git packaging workflow. We can view upstream version update clear in upstream branch. gbp-import-orig and routine-update also use upstream branch. The upstream branch will been updated automated by gbp-import-orig or routine-update, it's not need to do more thing to maintain.On 2024-06-14 13:02, xiao sheng wen(肖盛文) wrote:在 2024/6/14 16:25, Paride Legovini 写道:Hello,I can review and sponsor imv 4.5.0-1, but I prefer to work on salsa rather than on mentors. Some comments on the changes you pushed to debian/latest: (1) Past upstream imports were done via `gbp import-ref`, i.e. by adding an upstream remote and importing the upstream tag. This has the advantage of having the full upstream commit history in the packaging repo, and this is why d/gbp.conf had `upstream-branch =`, which you dropped in d8e53ea1. Now the import of 4.5.0 is done and I'm not going to ask you to revert an re-import via import-ref, however please revert d8e53ea1 to allow the next imports to be done from a tag via import-ref.I do a test on my local, I check out to old version debian/4.4.0-1 to restart import, even after drop `upstream-branch =` in d/gbp.conf, we still can use gbp import-ref -u4.5.0 to get the full upstream commit history in the debian/latest branch. I had push my test to: [...]It is true that we can keep an upstream branch, but it is not useful (if you need the pristine upstream source tree, just `git checkout TAG`), and it's one more thing to maintain, as when importing like: git remote update upstreamremote gbp import-ref -uVERSION the upstream branch is not updated, and will eventually become stale.
At present, when I run gbp import-ref, I'll get a warning info: gbp import-ref gbp:warning: This script is experimental, it might change incompatibly between versions. so gbp import-ref is not stable.
Use an empty upstream-branch gbp.conf setting to stop other use gbp-import-orig is not a better way.Moreover, having an empty upstream-branch gbp.conf setting signals that upstream sources should not be imported via gbp-import-orig, but in some other way (namely gbp-import-ref). Indeed you had to change that setting to import with gbp-import-orig.
imv is a team maintain package, it should not restrict use gbp-import-orig, even gbp-import-orig is used popularity.
Use uscan and gbp-import-orig is often used in gbp packaging workflow. routine-update also use the upstream branch, routine-update can packageIf we agree on the above then please revert d8e53ea1, otherwise I'm happy discussing the points above, but please begin providing a meaningful use case for the upstream branch in the context of a "pure git" packaging workflow.
new upstream version more easy,quick and automate. It save many times on packaging routine. Keep upstream commit log on debian-branch is also useful, but for most packaging situation, It's not need to investigate upstream commit. If only has debian directory change commit log in debian-branch, the whole package step will look more clear, git log also shorter. The important is, use upstream branch can also allow use gbp import-ref andgbp import-orig in the meanwhile. There is not conflict.One time use gbp import-ref, the next time use gbp import-orig to import new upstream version code is acceptable.
I'm sorry for this. I use Thunderbird, it reply email use text and html occasionally.Thanks, -- Paride PS: the text/plain part of your multipart mail is not well formatted, see the very long line above. I suggest sending pure plaintext mail to have a better idea of what others will see. Also see point 9 of https://www.debian.org/MailingLists/#codeofconduct.
I set use only text manual this time. Regards, -- 肖盛文 xiao sheng wen https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page:https://qa.debian.org/developer.php?login=atzlinux%40sina.com Debian salsa:https://salsa.debian.org/atzlinux-guest GnuPG Public Key: 0x00186602339240CB
OpenPGP_signature.asc
Description: OpenPGP digital signature
