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; [email protected] 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 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
