On 2024-06-19 09:57, xiao sheng wen(肖盛文) wrote:
> Hi,
> 
> 在 2024/6/18 18:07, 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:
>>> [...]
>> 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.
> 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.
> 
> 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.
> 
>>
>> 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.
> Use an empty upstream-branch gbp.conf setting to stop other use
> gbp-import-orig is not a better way.
> 
> imv is a team maintain package, it should not restrict use gbp-import-orig,
> even gbp-import-orig is used popularity.
> 
>> 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.
> Use uscan and gbp-import-orig is often used in gbp packaging workflow.
> routine-update also use the upstream branch, routine-update can package
> 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.

My point is: I would like for what you expressed in this last sentence
not to happen.

This said, given that the package is team maintained and "pure git" is
clearly not a team policy, I'll sponsor your upload.

--
Paride

Reply via email to