Xiyue Deng <manp...@gmail.com> writes: > Hi Nicholas, > > Nicholas D Steeves <s...@debian.org> writes: > >> Hi Manphiz, >> >> First: Do not import the newest upstream version right now! I don't >> have time to review the diff between it and 17.3.13, so stick with >> 17.3.13 for now. >> > > I haven't updated to any newer version and don't intend to. Will stick > to version 17.3.13 for your review. > >> Xiyue Deng <manp...@gmail.com> writes: >> >>> Nicholas D Steeves <s...@debian.org> writes: >>>> Xiyue Deng <manp...@gmail.com> writes: >>>>> Nicholas D Steeves <s...@debian.org> writes: >>>>>> Xiyue Deng <manp...@gmail.com> writes: >>> >>> It's been a while since my last mail, and I'd like to admit that my >>> understand of a Salsa repository vs upstream repository back then was >>> incorrect: if we want to include upstream repository data in any form >>> (e.g. in upstream branch, or dig-main-merge workflow), the Salsa >>> repository should be a super-set of the upstream repo, which means it >>> should include everything in the upstream repo (including tags) and have >>> Debian specific changes on top of that. I have fixed it and have pushed >>> all tags. >> >> I appreciate the effort; however, your "super-set" idea unfortunately >> tends to be wrong for the majority of Debian packages. Related to this >> topic, have you read Debian Policy §4 yet? > > I have reread policy section 4 and I think you are mostly referring to > the non-native package handling. By default, gbp uses pristine-tar to > manage upstream tarballs, and import the changes to the previous release > into the Debian upstream branch. I also see practices by importing > upstream vcs into the Debian upstream branch and use the upstream tags > to generate the tarballs, which is becoming more common in the > post-Jia-Tan world. I'm mostly using the latter handling here. > > I've also seen a mixed usage between this 2 variants by importing > upstream vcs into the Debian upstream branch and still uses gbp > import-orig with pristine-tar, which results in a no-change merge commit > in the Debian upstream branch and get the good bits of both worlds. > >> Congrats on DM, by the way! >> > > Thanks! > >> Thank you for importing and pushing upstream's release tag--the relevant >> one is what is needed. The rest are nice to have, but aren't necessary >> for Policy-compliant packages, nor for git repos that provide a workspace >> for these packages in VCS. >> > > Ack. > >>>> Also, as stated before, I won't touch anything dgit-related. >>>> >>> >>> No worries. Over the past few months I realized that dgit is compatible >>> with gbp layout, so that the way it works is compatible both ways. I >>> have also added a `debian/gbp.conf' matching the current practice at >>> [1][2]. >> >> Provide links in context. I've explained this at length before. Stop >> using end-notes for mentoring conversations. This is not a suggestion. >> > > OK. As I mentioned last time, I tend to miscount the reference number > if I put links separately and you may find more than one "[1]" > references, but I'll try to be careful. > >> Re: dgit: some history is only readable when using dgit, and that's why >> I'm categorically against it. That means no "pseudo-merges" and such. >> If you can use it without using the features that produce this effect >> then I'll continue to review your work. >> > > The only thing I use from dgit is the command to build the package (dgit > --gbp sbuild) and the only difference from "gbp buildpackage" is that it > will check for any uncommitted change. The package handling follows the > same gbp practice as documented in d/gbp.conf. So you don't need to > worry about the dgit specific handling as there isn't any. > >>>> - Update license to GPL-3+ following upstream changes >>>> + Clarify license to be GPL-3+ to be consistent with upstream >>>> >>>> doesn't address the issues I raised. >>>> >>> >>> Now added text to clarify the previous license and change date in >>> d/changelog[3]. >> >> changelog:L11 "Clarify license to be GPL-3+ to be consistent with >> upstream" is still a problem. Read Policy §4 and hopefully you'll see >> why. >> > > changelog:L11 now reads "Update license to be GPL-3+ following upstream > change"[1]. Also I think policy 4.5 only gives general requirements of > the content of d/copyright file and I think the current content of > d/copyright is following this practice. Can you point me to the > specific text to show what is problematic? > > [1] > https://salsa.debian.org/emacsen-team/web-mode/-/blob/master/debian/changelog?ref_type=heads#L11 > >>>> Overrides need to be documented, and properly documenting your work is >>>> something you still need to work on, and that frequently delays your >>>> reviews, so it's up to you. >>>> >>> >>> It looks like the benefit of this tag is still under debate[4]. Also I >>> think your other comment regarding Lintian tag priorities is a good >>> reference: `prefer-uscan-symlink' is experimental. Therefore I would >>> like to leave it as-is for now. >> >> Sounds good to me! :) >> >>>>> 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. >>>> >>>> That's a good point. Is there a way to do both at the same time? If >>>> so, lintian should be updated; >>> >>> Actually it looks like this tag is not a good example as it is under >>> debate and people are advocating for its removal[4]. >> >> In other words "lintian should be updated" ;) (see above) >> >>>> Given this, what do you think is the optimal solution for web-mode? >>>> >>> >>> I think in this particular case leaving as-is may be the best option to >>> avoid additional work given the tag is experimental (so not release >>> critical as you suggested later) and when its removal happens we don't >>> need to do more work in the future. >> >> Yup, this is the truth of lintian. >> >> Do you understand the difference between a warning and a suggestion? If >> someone says the following, would you call it a suggestion?: "Don't open >> that door, the room is filled with toxic gas." >> > > I believe a warning means something that is usually a mistake but if you > know what you are doing this could be what you want. An example I can > think of is you may be writing C code that is undefined behavior > according to the standard but may be an extension supported by a > specific compiler, such as a zero-length array at the end of a struct, > which you may realloc to a different size later. > > A suggestion is for something that works correctly for now but can be > misused or is deprecated with better practices. > >>>> Good perspective, and I'm happy to read that you're thinking about these >>>> things. Please use accurate language when speaking of lintian tags, >>>> because error != warning != info != pedantic != experimental, because >>>> errors and warnings are generally release critical. >>>> >>> >>> Ack. >> ... >>> I would also like to point out that I have taken the liberty to add >>> myself to the entry of `debian/*' in d/copyright because I believe my >>> commits qualify as intellectual contribution to the packaging work. >>> There are also commits from Thomas Koch, David Bremner, Sean Whitton, >>> and you. Thomas obviously qualifies based on the thread at[5]. I >>> believe David and Sean's commits are just for rebuilding the Emacs >>> addons against dh-elpa for transition, which are not actually work >>> related to the packaging of web-mode so I didn't add them. I think your >>> commits also qualifies, but since you are active I'll leave it up to >>> you. >> >> The bulk of my contribution to web-mode is archived in this RFS bug, >> which is then forwarded to debian-mentors and also archived there. What >> matters to me is not that my name is written in web-mode's copyright >> file for posterity, but that you learn from these interactions, produce >> better quality work, more efficiently complete reviews, etc. >> >> Yes, go ahead and add yourself, because you're right: in this case it's >> accurate :) >> > > Thanks for confirming. > >> Regards, >> Nicholas > > -- > Regards, > Xiyue Deng
Friendly ping for further comments. -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
