Nicholas D Steeves <s...@debian.org> writes: > reopen 1068605 > owner 1068605 ! > thanks > > Hi, > > Sorry I didn't ask this sooner, but would you prefer if I call you Deng, > or Xiyue, or something else? Conventions and understanding vary a lot > from place to place, after all.
No worries! My first name is Xiyue, but I acknowledge that this is probably difficult to pronounce in non-Asian countries or even outside of China, so feel free to call me Deng, or even my code name "manphiz" :) > > Xiyue Deng <manp...@gmail.com> writes: > >> Thanks for pointing out #1019031! Totally missed it. I'll opt for >> option 1 obviously. Updated team repo and mentors accordingly. > > You're welcome, and thank you. On a related note, have you read the > definitions for source and binary packages? > > #1019031 was filed against src:web-mode, so was hidden from the > bin:elpa-web-mode view. On the BTS the src:package view will display > bugs that affect each binary package as well as the src:package. ยง4 of > Policy has the definition, and here is another good resource: > > https://wiki.debian.org/Packaging/SourcePackage > Actually I should have noticed it through the tracker page[1], which has a panel showing all bugs reported against all source and binary packages. >> Also, accordingly to this comment from Tobias[1] it looks like there are >> opinions that prefer to reuse existing RFS bugs instead of filing new >> ones. Do you think it's OK to reopen this one? > > There are also people who maintain the opposite position, but in the > spirit of harmony I've reopened this bug. [edit: Be careful about only > waiting a day and then going ahead and doing something without having > received a reply, because when you "ask" for something, but then don't > actually wait for a reply, it can make you look disingenuous and/or > impatient and/or pushy.] > I acted fast this time as this is a RFS bug so by reopening I'm not overriding any other people's work and it gives me a higher chance to find a potential sponsor faster. But I acknowledge the concern you pointed out and will be cautious in future. (And I get you as a reviewer which is better than I expected and I'd say it "worked" in my favor :P) > Onto the review: > >>>>> * New upstream release > > Push the upstream tag to salsa, and find a way to mitigate this issue in > the future. > Thanks for pointing this out, and this is something that confuses me. According to the dgit-maint-merge(7) workflow, one should have a upstream branch tracking upstream git repo directly, so that when you merge a tagged release "git deborig" can directly use upstream tags to create the tarball. On the other hand, if we have salsa CI set up there is no upstream tag on salsa so it probably will fail at "git deborig" stage. Still, if I read the dgit-maint-merge workflow correctly (I could be wrong), it only requires a "upstream/%(version)s" tag when the upstream only releases tarballs or when we want to package a snapshot. So I'm not sure whether we always want to have "upstream/%(version)s" tags. Would like to hear your opinion on this. >>>>> * Set upstream metadata fields: Bug-Database, Bug-Submit, >>>>> Repository-Browse >>>>> * Update standards version to 4.6.2; no changes needed > > Update this, since a new Policy version was recently released. Did you > already work through the upgrade checklist stepwise, starting from > 4.3.0? > Yes, I reviewed the policy upgrading checklist[2] and there should not be any changes required (actually from 4.5.0 when Thomas last worked on it). The same applies to 4.7.0 which I've updated to in [3]. > "debian-devel-announce" is a low traffic list that will keep you > appraised of stuff like this. > Ack, and glad I've already subscribed. Just that I worked on web-mode a bit earlier than the announcement. >>>>> * Use https link of homepage in d/control >>>>> * Modernize d/watch using special substitute strings to be more >>>>> robust > > I'm happy to see this clear, concise, and useful phrasing. If you have > any pending not-yet-uploaded work that doesn't use this, please update > it. If you're interested in a nitpick, the key term is "substitution > strings" and not "[special] substitute strings" (see the manpages for > uscan and deb-substvars as well as codesearch.debian.net). > Ack. Dropping the "special" part in changelog[4]. >>>>> * Fix issues in d/copyright >>>>> - Clarify license to be GPL-3+ to be consistent with upstream > > This is unclear. Which licence was it before, and whose license are you > talking about? Web-mode is a non-native package and debian/* is > separate from the upstream source. Also, what does it mean to clarify a > license? > It used to be GPL-2, and I'm talking about the upstream license. The upstream updated it to GPL-3 in 2022, which was actually after Thomas last worked on the package. I think maybe I should change the wording to "Update license to GPL-3+ following upstream changes"[5] >>>>> - Update copyright year info for upstream >>>>> - Add copyright info for debian/* > > You added a license grant for debian/* where there was previously none > with no explanation, notes, nor justification. Are you sure you have > the right to do this? Contact debian-legal and ask them for a patch > review of your intended changes. > I checked upstream contributor list and didn't find the original maintainer in it, so I believe it's a mistake that there is no separate copyright section for debian/* which Thomas worked on and should be attributed to him. But I agree that I should consult debian-legal@ on how to properly handle this. I have sent a mail there[6] and CCed you. Let's wait for an reply. >>>>> - Add Upstream-Contact > > Thanks for this and for all the other work I didn't comment on. > > Here are some things you can work on while waiting for a reply from > debian-legal: > > * lintian-explain-tags prefer-uscan-symlink: if you're changing the > watch file then this should be addressed > I think this lintian tag is to some extent controversial. See bug#1001458[7] where point 2 of the bug submitter makes much sense to me, which is I think this lintian tag is marked experimental (X). I think if we want to promote the use of "filenamemangle" over "mode=git", we may probably consider suppressing this tag in dh-elpa like other lintian overrides. Wdyt? > * There's also a version qualifier in d/control that can be dropped. > Indeed. Dropped in [8]. I should start running janitor alongside lintian-brush :) > * Finally, have you installed and tested your updated package? > Yes, briefly. Though I'm not a heavy user of HTML templates, I did try out the examples/tests in web-mode source and they work once turning on web-mode. > * Extra/bonus: Which tags from the lintian output are candidates for > an override, and why? > Personally I think that most lintian tags suggest good practices but not all of them are applicable or suggestible. One example is the aforementioned "prefer-uscan-symlink" where the suggestion is local-only while the filenamemangle setting can be shared with the team. Another area I can think of is that upstream practice is different from lintian's recommendations but works well, like the shard library location warnings for native compiled eln which I believe dh-elpa overrides, or upstream may have a different form of copyright (like in Org in one of the packages I worked on) which is different from the recommended format. There must be more cases I haven't thought of. On the other hand, I believe lintian should and is also evolving to accommodate newer use cases and deprecate obsolete practices. > -N > -- Xiyue Deng [1] https://tracker.debian.org/pkg/web-mode [2] https://www.debian.org/doc/debian-policy/upgrading-checklist.html [3] https://salsa.debian.org/emacsen-team/web-mode/-/commit/a401932c84c9705cd11e762785bc603a17bdd5a8 [4] https://salsa.debian.org/emacsen-team/web-mode/-/commit/f1eebd25ee3a878695e8e68c7203cf2eff1223d0 [5] https://salsa.debian.org/emacsen-team/web-mode/-/commit/d7dfdcaf7a4ba4ec1103bf01294602a964448303 [6] https://lists.debian.org/debian-legal/2024/04/msg00001.html [7] https://bugs.debian.org/1001458 [8] https://salsa.debian.org/emacsen-team/web-mode/-/commit/ddc2a5422671222e6f29e348679ea98b46df44bc
signature.asc
Description: PGP signature
