RFS: imv/4.5.0-1 [Team] -- X11/Wayland image viewer intended for use with tiling window managers

[Paride Legovini]

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:
> https://salsa.debian.org/atzlinux-guest/imv/-/commits/debian/latest-has-upstream-commit-history/?ref_type=heads My test setting is: git remote -v atzlinux git at salsa.debian.org:atzlinux-guest/imv.git (fetch) atzlinux git at salsa.debian.org:atzlinux-guest/imv.git (push) upstream-imv https://git.sr.ht/~exec64/imv (fetch) upstream-imv https://git.sr.ht/~exec64/imv (push) There is a new version tag in remote upstream repo upstream-imv: commit 8f36d35ff6a844de7d338a4e9b34bc98f114014b (tag: v4.5.0, upstream-imv/master) run "gbp import-ref -u4.5.0" will automate find this tag and import commit history. so, revert d8e53ea1 is not necessary. The gbp default upstream-branch is upstream, this don't to interference use gbp import-ref.

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.

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.

If 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.

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.