Hi Antoine! It seems I forgot to push my work on this package from early 2020 :-/ Probably fell asleep...I'm truly sorry for wasting your time in the initial review. Reply follows inline; feel free to skip the rest of this email if you're busy. The package should meet your standards @a69fbc3. OT, I wish the sponsorship template would insert commit:@foo...that would have prevented this, and I think the pkg on mentors was @a69fbc3... Antoine Beaupré <anarcat@debian.org> writes: > i am not sure, but i suspect it is a mismatch between the > debian/changelog and debian/control package names. indeed, with the > following patch: > [snip] > -atomic-chrome (2.0.0-1) unstable; urgency=medium > +atomic-chrome-el (2.0.0-1) unstable; urgency=medium [snip] > ... the package compiles. > Indeed. Fixed 1 Jan 2020 (many apologies, I forgot to push). > The other issue I found is what now seems to be a recurring disagreement > between us. :) This is the tarball that `uscan` gives me when I run the > above command: > [snip] > There are a few things wrong here: > > 1. we should not needlessly differ from the upstream tarball > Yeah... I did special-case your preference 29 March 2020 (forgot to push). [1a] That said, in addition to what we discussed before, I'm finding that more and more projects release less-than useful tarballs eg: missing tox.ini or other things for self-tests. Fundamentally, the only reason I use a tarball check in the watch file is to reduce the load on the system that runs uscan (daily?). I would move everything over to pure git (with a quilt patch series, if necessary) in a heartbeat if using git in the watch file wouldn't make people grumble. > 2. if we really have to, `uscan` should allow us to reconstruct our > tarball reproducibly, or at least `README.source` should explain > how. at minimum, `README.source` should explain *why* we differ > [2a] I'm still not convinced of the value of this when it's fetchable with 'apt source', 'dgit clone', or 'dget'. That copy is gpg signed via the changes and/or dsc, and benefits from our (Debian) identity verification. Re: README.source, I don't know about this one...Lamby convinced me not to use README.source for this purpose some time ago. I used to always document when I was using a git tag rather than upstream release tarball :-) > 3. even if we insist on using `xz` (and I don't see why we do in this > case), we don't need the maximum compression level. this is a small > package and there's not reason to "crank it up to 11", so to speak :) > [3a] :-) I agree with you that it doesn't have much practical value for a package of this size, but there is a reason: establishing policy. I think it was spwhitton who impressed on me the value that the accumulation of packaging decisions affects trends, consensus, and ultimately Policy. The practical value is that if maintainers are willing to "crank it up to 11" even for little packages, then it's fair to expect the same from maintainers of packages where the diff is large. I'd give up on this with proof that weaker compression resulted in less net electricity consumption (including ongoing storage and transmission) than what is required for compression and decompression of xz. If you know, please share! > The following patch should fix the problem: > > From a9dc9a10a4c1ea9024a70335232dd837d36738d1 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anarcat@debian.org> > Date: Fri, 17 Apr 2020 21:01:14 -0400 > Subject: [PATCH] remove superfluous diff with upstream tarball > Thank you for the patches, I sincerely appreciate that you took time to write them. Once again, sorry for not realising I hadn't pushed... > I feel uncomfortable sponsoring a package if it doesn't use the upstream > tarballs. I hope you'll understand. > Definitely! I've been mentoring some new Emacsen Team members, and wrote up a short hierarchy of priorities. The standards of one's sponsor are #1, unless they contradict Policy. Anyways, it has both conceptual and practical dimensions. Here's a practical one you'll appreciate: tldr (pithy synopsis), don't drain your sponsor with unnecessary arguments or they'll be too drained to review and sponsor your work ;-) If you're interested in reading it and/or if you think such a thing would make a good addition to an existing doc, please let me know! Cheers, Nicholas
Attachment:
signature.asc
Description: PGP signature