Hi Samo, On Sun, Feb 16, 2025 at 7:43 PM Samo Pogačnik <samo_pogac...@t-2.net> wrote: > > Hi Bo, > > On Sun, 2025-02-16 at 14:09 +0800, Bo YU wrote: > > Hi Samo, > > > > On Sat, Feb 15, 2025 at 09:01:06PM +0100, Samo Pogačnik wrote: > > > Hi Bo, > > [...] > > > > > > > > > And one more question. Is it a ok that git history now contains previous > > > commit > > > messages 'Release 0.4.9-2' and 'Release 0.4.9-3', as they will/might > > > repeat > > > in > > > future commits? I tried to address this through the commit message of this > > > change: > > > > No, it is not needed. In fact this hint should not be in the commit also. > > this will give hint to other developers, so this is up to you.:) > > > > If I were you, maybe I will use > > > > Update changelog for 0.4.9-2 again > > > > instead of your commit. > > > > Thanks for that. > > > There are lots argue about Debian packaging workflow with git repo, but > > git repo is just to help packaging maintenance, in other words, > > packaging should not be subjected to git. But good git history or > > maintenance will help you to get maintainer permission even to become a > > DD later. > > > Noted:) > > > Back to git-subrepo itself, there are some improvements I think: > > > > > +git-subrepo (0.4.9-2) UNRELEASED; urgency=medium > > > > > > + * Reordered and rewritten existing patches (Closes: #1078960) > > > + * Added patches to fix upstream PR checks > > > > Added xx.patch for the uploading, like > > > > * Added xx.patches to fix upstream PR checks > > > I fixed that with a different wording (found in your strace d/changlelog) as > patch names are so long: > * Added patches to fix upstream PR checks: > - 0005-Fixing-shellcheck-errors-found-during-docker-test.patch > - 0006-Fixing-tests-running-on-macos-github.patch > > > > + * Fixing git-subrepo, when ff=only is set in git > > > > I think there is one patch to fix this, right? > > > Thanks for that. You are right that there is one patch fix, but there is > another > patch to set test environment (git-config) to enforce testing the fix. So i > amended the changelog like this: > * Added patch to set project-wide ff_only git-config for pull and merge > during tests: > - 0007-Set-project-wide-ff_only-git-config-for-pull-and-mer.patch > * Added patch to fix git-subrepo command and its tests, when ff=only is > set in git-config: > - 0008-Fixed-git-subrepo-and-tests-if-set-ff_only.patch >
Great! These items are more explicit. > > > * d/control: update Standards-Version to 4.7.0 > > > * d/control: bump debhelper compat level to 13 > > > * d/control: added Multi-Arch: same > > > + * Acknowledge the previous upload (Closes: #1081945) > > > > > > - -- Samo Pogačnik <samo_pogac...@t-2.net> Sat, 11 Jan 2025 17:41:16 > > > +0000 > > > > basiclly, you should let others know what you have modified without > > comparing > > line by line of code. > > > Yes, thanks. > > > Because you are one maintainer withuot uploading permission, so we would > > be to avoid to use these words as the commit before get sponsorship > > otherwise you will be a dilemma position if your sponsor to ask some > > updates, > > just like your current confusion.:) > > > > > Update changelog for 0.4.9-2 release > > By 'these words', you ment referring to a specific release version in git > commits? Yes. If your sponsor asks for some updates this will add new git commit to over the commit which including specific release version or force push. But if you are one maintainer or DD with uploading right, you can decide to what to upload, so specific release version in git will make sense. But in general, we will use this to get ready for uploading: Prepare for upload or Prepare for upload to unstable/experimential See https://salsa.debian.org/python-team/packages/python-tksheet/-/commits/debian/main?ref_type=heads Once you or your sponsor upload your package to unstable, there should be one debian/version tag to push debian git repo, and please notice, there are no any new commits in there. For my python-tksheet again, see debian/7.3.4-1[0] and heads then to compare the two commits hash, they are the same. So this is what I want to express, we do not need a special debian version in commit, tags will hit this. And please refer to the email[1] again, this logical is consistent. [0]: https://salsa.debian.org/python-team/packages/python-tksheet/-/tree/debian/7.3.4-1?ref_type=tags [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979188#282 > > > We can use UNRELEASED or unstable as the review/sponsor singal or just > > one actual commit id that is okay. > > > If i understand correctly, the change from UNRELEASED to unstable would > indicate, that changes are prepared for upload by a DD, when a real upload is > in > question or by a DM, when uploading to mentors looking for a sponsor. > I think the answer is yes. But every DD/team is different, but in generally, the sponsor will not touch any code to upload sponsored packages but but there are exceptions also. So the `UNRELEASED` switches to unstable that is safe to upload to mentors. This tag is specially useful in team maintenance, this will tell others the version is not ready to upload but others can add new entries under the version. > > Let's go ahead. > > I bravely pushed to debian/git-subrepo as well:) Thanks, please change the distribution to unstable and upload it to mentor again. I am ccing Phil here.:) Thank you. BR, Bo > > best regard, Samo >
