Bug#1011594: Re: kotlin-mode needs a source-only upload for testing migration
Hi Josh, Joshua Peisach writes: > Hi Nicholas, I'm sorry for bunting. I really should be working with > the emacsen team and using other examples. It's a great team to learn from :) > For this, I have created a branch called '1011594-fixes' which aims to solve > these problems. > > Before reading, just want to say that you aren't being harsh. You're giving > the 'deeply concerned and worried' attitude, not the 'how dare you' mood. You > went into a lot of depth with the problems, and you are looking out for me. > For what I am doing, it is sensible for me to do the work, so this is a good > "pause and think" moment. I greatly appreciate it, no matter how deep of a > hole I may be digging for myself. :) > Fiouf, I'm relieved the tone came through clearly, and wow, thank you for your kind words :) > 1. > Changelog for 'upstream release' - Using ggtags as an example, I'm > setting that to "Update to new upstream commit" - > https://salsa.debian.org/emacsen-team/ggtags/-/blob/master/debian/changelog This is accurate, and "upstream snapshot" is equally acceptable. > 2. The patch. I had to fresh the patch. Honestly, I took the lazy > route since I did not do this in a while and just.. created a new > one and put your name down as the 'first' author to show you did it > first. > * First: In terms of a FOSS project, what I did was > tremendously dumb. I should've thought about what I was doing but > I didn't. I was focused on getting the thing done by just doing > what was needed to get dpkg-source and quilt apply the patch > happily. and next time I need to think logistically about how to > handle this. It sounds like you know that mistakes are learning opportunities, and that "dumb" is when you don't learn from mistakes, and finally that you've learned from this experience :) That's excellent, and not dumb. I hope it was also fulfilling and fun--by the way, making learning fun is the trick to learning things faster, with less repetition. In addition to working with the patch series directly with the "quilt" command, "gbp pq" from git-buildpackage, as well as the "dgit-maint-*" tools from dgit. I know DDs who will only use quilt directly, so don't feel pressured to switch if that's the one you prefer. Other teams insist on a particular tool, and you're use kotlin-mode to practice skills that will transfer to those other teams. > * The wording I did was taken from you, for the 'Declare > correct MELPA version'. The text in the patch is taken directly > from the file. If it helps you understand what I did, I created > an entirely new patch. I did the quilt new, quilt add, > (edit-file-command), quilt refresh, quilt header -e --dep3, quilt > pop. Ahh. If you're interested, we can do an intro to patch headers later, without the pressure of deadlines. > * My current step process: I have reverted the commit (git > revert. I rarely revert commits, and I try to avoid force pushing > unless I'm tremendously lost). I am running back to Chapter 8 of > the maintenance guide, setup dquilt and am following the updating > patch part of section 8.3, under the conflict part with the new > upstream source. I edit kotlin-mode.el file, ran dquilt push and > refresh, going back to 8.1 for changelog. Using projectile's > changelog as an example, and I'm saying "Refresh patch 0001 > (update source version)" Thank you for sharing your workflow and noting you use dquilt too. Yes, I know that it's an Ubuntu tool that isn't in Debian. Is that maintenance guide a Debian or an Ubuntu one? All of this is fine, in my view, so long as packages you work on build on Debian, function properly on Debian, and meet the mandatory standards for Debian. Someday, if you work on more difficult packages, setting up a Debian devel and build environment will become a necessity, but there's no need to stress about this for now. One nitpick is "update source version", because "source version" can be interpreted ambiguously. I believe it's arguably more accurate and unambiguous to write something like "update corrected upstream version". I didn't correct that. > 3. Standards Version - I always use the updating checklist! It's > the most helpful tool. Ran through both 4.6.1 and 4.6.2. I took your > suggestion for "Declare compliance with.." though I've always used > "Update Std-Ver". For a second changelog point, I should've put that > in but I did not. For reasoning, I will say that the file says > required emacs 24.3 and buster has 1:26.1+1-3.2+deb10u3. Plus, for > bookworm the current emacs version is 1:28.2+1-10. Users keeping > their system up-to-date meet the constraint. :) I'm happy to hear you use (and like!) the checklist. Your reasoning is sound, and yes, the changelog is now much better, and to my view now demonstrates understanding. > 4. Copyright years - I am a bit
Bug#1011594: Re: kotlin-mode needs a source-only upload for testing migration
Hi Nicholas, I'm sorry for bunting. I really should be working with the emacsen team and using other examples. For this, I have created a branch called '1011594-fixes' which aims to solve these problems. Before reading, just want to say that you aren't being harsh. You're giving the 'deeply concerned and worried' attitude, not the 'how dare you' mood. You went into a lot of depth with the problems, and you are looking out for me. For what I am doing, it is sensible for me to do the work, so this is a good "pause and think" moment. I greatly appreciate it, no matter how deep of a hole I may be digging for myself. :) 1. Changelog for 'upstream release' - Using ggtags as an example, I'm setting that to "Update to new upstream commit" - https://salsa.debian.org/emacsen-team/ggtags/-/blob/master/debian/changelog 2. The patch. I had to fresh the patch. Honestly, I took the lazy route since I did not do this in a while and just.. created a new one and put your name down as the 'first' author to show you did it first. * First: In terms of a FOSS project, what I did was tremendously dumb. I should've thought about what I was doing but I didn't. I was focused on getting the thing done by just doing what was needed to get dpkg-source and quilt apply the patch happily. and next time I need to think logistically about how to handle this. * The wording I did was taken from you, for the 'Declare correct MELPA version'. The text in the patch is taken directly from the file. If it helps you understand what I did, I created an entirely new patch. I did the quilt new, quilt add, (edit-file-command), quilt refresh, quilt header -e --dep3, quilt pop. * My current step process: I have reverted the commit (git revert. I rarely revert commits, and I try to avoid force pushing unless I'm tremendously lost). I am running back to Chapter 8 of the maintenance guide, setup dquilt and am following the updating patch part of section 8.3, under the conflict part with the new upstream source. I edit kotlin-mode.el file, ran dquilt push and refresh, going back to 8.1 for changelog. Using projectile's changelog as an example, and I'm saying "Refresh patch 0001 (update source version)" 3. Standards Version - I always use the updating checklist! It's the most helpful tool. Ran through both 4.6.1 and 4.6.2. I took your suggestion for "Declare compliance with.." though I've always used "Update Std-Ver". For a second changelog point, I should've put that in but I did not. For reasoning, I will say that the file says required emacs 24.3 and buster has 1:26.1+1-3.2+deb10u3. Plus, for bookworm the current emacs version is 1:28.2+1-10. Users keeping their system up-to-date meet the constraint. 4. Copyright years - I am a bit embarrased to say I had no idea Threshold of Originality is a thing. Looking at other examples, best thing to do is leave it. Unfortunately I cannot quite meet the 'one-time history change' as I have already used it on the patch, but I can offer you a commit that just takes off the -2023 with an explanation. Not every file has changed, and it seems there are different rules of threshold of originality per country. I am in the US personally, and I think I meet the "small value" but I don't feel like risking it. I have just updated the changelog, made commits, the tests passed, ran lintian and fixed the changelog line being too long, updated changelog time again, committed and pushed. If possible, can you review the branch? Thanks again for checking everything out, and I am so sorry for all the problems created. -Josh From: Nicholas D Steeves Sent: Monday, January 30, 2023 10:48 PM To: Joshua Peisach; 1011...@bugs.debian.org Subject: Re: Bug#1011594: Re: kotlin-mode needs a source-only upload for testing migration Hi Josh, Thank you for the quick reply, and for updating the maintainer :) I've tried to write an email that will help you understand the issues with as quickly as possible, since the final deadline is days away. 'hope it's not too long or harsh As you know, Debian has high standards, and you may remember some of this from our first review. When you didn't follow up, I fixed the remaining issues myself (see 30eb8be to faef886); This time around, please resolve the issues noted below yourself, before the 5th of February. If you're short on time and want to take the fastest path, skip to the paragraph that starts with "If you want". Upstream has not made a release, so the first changelog point is wrong. What is really being packaged? d51515f * Refresh and update patches - I would write the following no matter who the original author of the patch was: This looks like an attempt to take credit for someone else's work by making some some changes that aren't significant for the purposes of copyright; this sort of thing w
Bug#1011594: Re: kotlin-mode needs a source-only upload for testing migration
Hi Josh, Thank you for the quick reply, and for updating the maintainer :) I've tried to write an email that will help you understand the issues with as quickly as possible, since the final deadline is days away. 'hope it's not too long or harsh As you know, Debian has high standards, and you may remember some of this from our first review. When you didn't follow up, I fixed the remaining issues myself (see 30eb8be to faef886); This time around, please resolve the issues noted below yourself, before the 5th of February. If you're short on time and want to take the fastest path, skip to the paragraph that starts with "If you want". Upstream has not made a release, so the first changelog point is wrong. What is really being packaged? d51515f * Refresh and update patches - I would write the following no matter who the original author of the patch was: This looks like an attempt to take credit for someone else's work by making some some changes that aren't significant for the purposes of copyright; this sort of thing will eventually make you look bad and/or get you into trouble, so I'm raising it as an issue now. The patch was already DEP-3 compliant, and you removed the original authorship date. Also, the "Debian package number" is "-1" for both the upstream versions mentioned in this changelog... Make only the required two line change, as well as adding the recommended "Last-Update" field. Think about it this way: 1) You are the steward of a patch written by and © someone else. This will sometimes (but not always) happen if you neglect your package when it has issues. Consider reading about Salvaging and NMUs. 2) You should document your changes to the patch[es], and the reasons for your changes in debian/changelog. 3) Likewise, you are the steward of upstream software, and should document your changes, reasons for the changes, as well as technical decisions in d/changelog. - The changelog entry needs to say what you did, what you changed, and why. Did you copy this text from somewhere? I ask because there is only one patch. 101827a * Update Std-Ver, no changes required, remove unnecessary constraint - Should be two commits, and must be two changelog points. These two changelog points must say what one actually did. Here is a nice unambiguous line that was taught to me when I was starting out: * Declare compliance with Standards-Version x.y.z (no changes required). And one can only claim that after verifying that the package is in fact Policy version x.y.z-compliant: https://www.debian.org/doc/debian-policy/upgrading-checklist.html Did you verify if the package was Policy version x.y.z compliant? With which version? As for the second point, you need to say what the "unnecessary constraint" was, as well as why it's now unnecessary. A second reason to say what and why is because you don't want it to look like you plagiarised a robot's MR: https://salsa.debian.org/emacsen-team/kotlin-mode/-/merge_requests/1 00a3d78 * Update copyright years - To add 2023 requires having made work that meets the minimum threshold of originality. https://en.wikipedia.org/wiki/Threshold_of_originality I would be happy to help you gain the understanding that is necessary to write good enough changelog entries to meet that threshold of originality. If you need any hints, pointers, or explanations, don't hesitate to ask. If you want to stage your changes in a feature branch and have me review them there, I'd be happy to use that approach[1]. Also, for small packages, I offer one free git hard reset and/or history rewriting event, which you may use at any time. Take care, good luck, and have fun! Nicholas [1] https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow signature.asc Description: PGP signature
Bug#1011594: Re: kotlin-mode needs a source-only upload for testing migration
Hi, Review on the repo here on this bug is okay! I am sending this to the bug email, and I've also updated the maintainer. Thanks -Josh From: Nicholas D Steeves Sent: Friday, January 27, 2023 2:59 AM To: Joshua Peisach ; 1011...@bugs.debian.org <1011...@bugs.debian.org> Cc: Adrian Bunk ; Hans-Christoph Steiner Subject: Re: Bug#1011594: Re: kotlin-mode needs a source-only upload for testing migration Hi Josh, Joshua Peisach writes: > Hi Nicholas, > > I have imported the latest upstream snapshot into Salsa :) > Thank you! I've reviewed the new commits, and the current state of the git repo is not yet ready to sponsor. Would you like the review to occur at this (#1011594 "Please package new upstream snapshot") bug, at a yet-to-be-filed RFS bug, or on the Emacsen Team or Debian mentors mailing list? Debian is developed in the open, so private mail isn't an option. Alternatively, if you'd like to learn or practise "Git Feature Branch Workflow" [1], then I'm happy to review that way too. IMPORTANT: We're in the "Freeze"[2] so deadlines are in effect. This work has to be completed before the end of next week. Cheers, Nicholas [1] https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow [2] https://release.debian.org/bullseye/freeze_policy.html P.S. Also, I'm still waiting for you to make the following change: diff --git a/debian/control b/debian/control index 6576d4e..8ae5a20 100644 --- a/debian/control +++ b/debian/control @@ -1,7 +1,8 @@ Source: kotlin-mode Section: editors Priority: optional -Maintainer: Joshua Peisach +Maintainer: Debian Emacsen team +Uploaders: Joshua Peisach Build-Depends: debhelper-compat (= 13), dh-elpa Standards-Version: 4.6.2
Bug#1011594: Re: kotlin-mode needs a source-only upload for testing migration
Hi Josh, Joshua Peisach writes: > Hi Nicholas, > > I have imported the latest upstream snapshot into Salsa :) > Thank you! I've reviewed the new commits, and the current state of the git repo is not yet ready to sponsor. Would you like the review to occur at this (#1011594 "Please package new upstream snapshot") bug, at a yet-to-be-filed RFS bug, or on the Emacsen Team or Debian mentors mailing list? Debian is developed in the open, so private mail isn't an option. Alternatively, if you'd like to learn or practise "Git Feature Branch Workflow" [1], then I'm happy to review that way too. IMPORTANT: We're in the "Freeze"[2] so deadlines are in effect. This work has to be completed before the end of next week. Cheers, Nicholas [1] https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow [2] https://release.debian.org/bullseye/freeze_policy.html P.S. Also, I'm still waiting for you to make the following change: diff --git a/debian/control b/debian/control index 6576d4e..8ae5a20 100644 --- a/debian/control +++ b/debian/control @@ -1,7 +1,8 @@ Source: kotlin-mode Section: editors Priority: optional -Maintainer: Joshua Peisach +Maintainer: Debian Emacsen team +Uploaders: Joshua Peisach Build-Depends: debhelper-compat (= 13), dh-elpa Standards-Version: 4.6.2
