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
