Xiyue Deng <[email protected]> writes: > Aymeric Agon-Rambosson <[email protected]> writes: > >> Hello Xiyue, >> >> Sorry for the late answer, and thank you very much for the >> clarifications. >> >> Le mardi 27 janvier 2026 à 16:26, Xiyue Deng <[email protected]> a >> écrit : >> >>> Hi, >>> >>> Xiyue Deng <[email protected]> writes: >>> >>>> (With permission to reply to list from Aymeric.) >>>> >>>> Hi Aymeric, >>>> >>>> Aymeric Agon-Rambosson <[email protected]> writes: >>>> >>>>> Hello, >>>>> >>>>> Le jeudi 8 janvier 2026 à 16:45, Xiyue Deng <[email protected]> a >>>>> écrit : >>>>> >>>>>> Hi Sean, >>>>>> >>>>>> Sean Whitton <[email protected]> writes: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Xiyue Deng [07/Jan 6:58pm -08] wrote: >>>>>>>> I thought the existence of pristine-tar branch indicates the >>>>>>>> workflow. >>>>>>> >>>>>>> It does, but you're the maintainer now, so it's okay to take >>>>>>> steps >>>>>>> towards modernisation. >>>>>> >>>>>> Ack. I think for maintaining max compatibility, we can just mark >>>>>> the >>>>>> branches `upstream' and `pristine-tar' as read-only by setting >>>>>> `Allowed >>>>>> to merge' and `Allowed to push and merge' to `No one' instead of >>>>>> deleting those branches. This requires one to have a Maintainer >>>>>> role >>>>>> though. >>>>>> >>>>>> Also, as there are other magit uploaders, I have CCed them here >>>>>> to >>>>>> see >>>>>> whether there is any objection to migrate magit to the >>>>>> dgit-maint-merge >>>>>> workflow. If no objection is received by the end of next week, >>>>>> I'll >>>>>> request the Maintainer access and mark the branches >>>>>> read-only. And >>>>>> do >>>>>> let me know if you want to extend the decision period. >>>>> >>>>> I prefer the current workflow. You managed to explain it in less >>>>> than >>>>> 20 lines in commit 7061b8aa. >>>>> >>>> >>>> To be clear, if by the "current" workflow you meant what we have >>>> been >>>> doing in the recent uploads since 4.3.2 (around the time I started >>>> working on magit) and before the latest 4.5.0, we actually had been >>>> using the dgit-maint-merge workflow effectively. See below. >>>> >>>>> And it does not even require gbp. You wrote : >>>>> >>>>>> And then switch to the `master' branch and do the usual `gbp >>>>>> import-orig --uscan'. The upstream tag will be `vX.X.X' and the >>>>>> Debian upstream tag will be upstream/X.X.X. The pristine-tar >>>>>> branch >>>>> >>>>> But you can simply go back to the master branch and merge the same >>>>> tag >>>>> you merged to the upstream one : >>>>> >>>>> ,---- >>>>> | $ git branch master && git merge vX.X.X # vX.X.X is the latest >>>>> versioned tag >>>>> `---- >>>>> >>>> >>>> This is exactly how the dgit-maint-merge workflow works. Notice >>>> that >>>> this does not involve the Debian "upstream" branch at all. >>>> >>>> In fact, the last push to the Debian upstream branch before the >>>> 4.5.0 >>>> release was done at the time when 4.3.1 was released, which was >>>> some >>>> time after Bookworm and well before Trixie. >>>> >>>> The problem with the current Debian upstream branch is that it is >>>> not >>>> exactly the same as the Magit upstream git (and as a result the >>>> Debian >>>> upstream tag `upstream/X.X.X' is not the exact upstream tag >>>> `vX.X.X'), >>>> which breaks the expectation of tag2upload[1]. And as I mentioned, >>>> we >>>> have not been using the Debian upstream branch at all for quite >>>> some >>>> time before 4.5.0. >>>> >>>> For the dgit-maint-merge workflow, a maintainer should have an >>>> upstream >>>> repo setup and merge the tags directly into the Debian master >>>> branch, >>>> which we have been doing. >>>> >>>>> If the point is just to use upstream tags and not pristine-tar, >>>>> then >>>>> there is nothing to change to the workflow : just do not commit >>>>> anything to the pristine-tar branch. >>>>> >>>> >>>> And AAMOF we didn't commit to the Debian upstream branch either. >>>> >>>>>> I thought the existence of pristine-tar branch indicates the >>>>>> workflow. >>>>> >>>>> Not necessarily. I never use it, and I forget to commit the tar to >>>>> the >>>>> pristine-tar branch half of the time. >>>>> >>>> >>>> Ack. Same here before I notice the existence of pristine-tar. >>>> >>>>> Remove the pristine-tar branch if you must (or better yet, just >>>>> ignore >>>>> it), but please leave the upstream branch. >>>>> >>>> >>>> I think by "the upstream branch" you meant the Magit upstream >>>> branch? I >>>> would make both the Debian upstream and pristine-tar branches >>>> read-only >>>> to avoid any accidental commits there given the reasoning above. >>>> >>>> Let me know what you think. >>>> >>>>> Best, >>>>> >>>>> Aymeric >>>>> >>>> >>>> Thanks! >>>> >>>> [1] See also Ian's reply to the long thread regarding including >>>> commit >>>> id in *.changes where "gbp import-orig --uscan" should be >>>> discouraged >>>> due to the divergence in the upstream branch: >>>> https://lists.debian.org/debian-devel/2026/01/msg00127.html >>> >>> On reading the recent debate on d-d@, I saw one proposal that >>> suggested >>> to add "upstream-vcs-tag" to d/gbp.conf. With this, `gbp >>> import-orig >>> --uscan' will import the full upstream history with a no-change >>> commit >>> (either to the tag or HEAD) to our upstream branch. This seems to >>> be >>> very close to the dgit-maint-merge workflow and people can still use >>> `gbp import-orig --uscan'. We can also stop using pristine-tar >>> (right >>> after my previous silly attempt) for good and things should continue >>> to >>> work. >> >> If I understand correctly, does this mean that our upstream branch >> remains after all ? >> > > Yes. Though I believe it is different from what you were referring to: > if you were using "git checkout master && git merge vX.X.X", the tag you > are merging from is from the Magit upstream branch, not Debian upstream > branch. This is the dgit-maint-merge workflow, in which only the > `master' (or debian/latest as in DEP-14) is used; no Debian upstream > branch is actually used here[1]. > >>> I think this is also compatible with tag2upload, though one may need >>> to >>> specify which upstream tag to use when running `git debpush' since >>> this >>> may create 2 upstream tag: one like `v?%(version)s' and one like >>> `upstream/%(version)s'. >>> >>> (Adding Sean to CC to confirm whether the above is true or is >>> recommended.) >>> >>> I haven't heard back from Aymeric, but hopefully this arrangement >>> will >>> meet his expectation as well. >> >> I'm good as long as you can assure me that the simple workflow I >> described on my last mail still works. >> > > It would be different though: dgit-maint-merge workflow will directly > use upstream main branch and upstream tags; while `gbp import-orig > --uscan' will create new commits in the Debian upstream branch, making > it diverging from upstream main branch. Let me try to make it clearer > by using Magit branching graph. > > An example for dgit-maint-merge workflow will look like below (using an > example from magit packaging): > > ,----[ dgit-maint-merge workflow ] > | 160c8a40 * Merge tag 'v4.4.2' > | |\ > | b828afbb | * v4.4.2 Release version 4.4.2 > `---- > > Notice that we directly merge the upstream tag `v4.4.2' (b828afbb) into > our Debian `master' branch (160c8a40). No actual Debian upstream branch > is involved. > > On the other hand, using `gbp import-orig --uscan' with > `upstream-vcs-tag' will look like below (example from emacs-corfu > packaging): > > ,----[ `gbp import-orig --uscan' with `upstream-vcs-tag' ] > | 077e35b * Merge tag 'upstream/2.8' into debian/master > | |\ > | 4680970 | * upstream/2.8 debian/upstream/latest New upstream version 2.8 > | | |\ > | fbbcdf9 | | * 2.8 upstreamvcs/main Version 2.8 > `---- > > Notice that `2.8' is the upstream tag. After running `gbp import-orig > --uscan --upstream-vcs-tag=%(version)s', it will create a no-change > commit in the Debian upstream branch (4680970) from the upstream branch > (fbbcdf9), add a Debian tag `upstream/2.8', and then merge into our > debian/master branch (077e35b). Though this may cause a divergence in > our Debian upstream branch compared to upstream main branch, it should > be harmless and still compatible with tag2upload[2]. > > I believe you prefer the first alternative which is also what I'm > proposing now. Other people more familiar with gbp may prefer the > second workflow. Note that since the divergence in Debian upstream over > upstream main branch has already happened, so it may no longer be > identify anymore, so if we want to keep using the Debian upstream > branch, we have to use the second workflow or something comparable. > > Personally I don't have a strong preference. It would be great to hear > which one people would prefer. >
Friendly ping for comments :) >> Best, >> >> Aymeric >> > > [1] Well, there is a possibility that the Debian upstream (or > upstream/latest as in DEP-14) branch is exactly the same as upstream > main branch, in which case there is no difference. > > [2] You do have to specify which upstream tag to use as the contents of > both tags are identical. Using either is fine, and I think Ian prefers > the upstream one over the Debian one. -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
