Hi Josh, Joshua Peisach <itzswirlz2...@outlook.com> 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 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. > Sounds good to me, and yes, I agree this is the fastest and most certain thing to do right now. With further contributions this next year, I believe you will be able to claim © in 2023 :) The practical application of having a sense of this threshold will be a consciousness of when it's "ok to copy and paste" (because it's generic) vs when a license becomes significant. This is also significant when contributing to a collaborative project. More copyright holders means more people to ACK a potential licence change (ie: this is why the Linux kernel will almost certainly forever be GPL-2-only). In Debian we tend to be stricter than the minimum legal requirements, and the mentorship process is about building strong technical and social foundations. > 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? > Done, merged, and uploaded. Congrats on your success, and thank you for your contribution. I inferred this was your intent, because you finalised the changelog. Also, time is of the essence for a package that isn't in testing with the second freeze deadline only a week away. The installation of the doc/ subdir had two problems, so I disabled that, and will be filing a bug soon. I will expect you to fix that issue before the hard freeze. How could you have detected these issues? Use lintian, especially an up-to-date version like 2.116.3 (bookworm) or 2.115.1~bpo11+1 bullseye-backports. Lintian should be an automatic part of your package QA. > Thanks again for checking everything out, and I am so sorry for all the > problems created. > It's ok. The mentorship process is a safe space to make mistakes, learn, and gain confidence. You met the deadline I set, I reviewed your work and wrote this email during the timeline I anticipated needing, and I'm uploading the package with what I believe will be enough time for it to make it into testing/bookworm and thus Debian 12. Regards, Nicholas
signature.asc
Description: PGP signature
