Control: noowner -1 Xiyue Deng <manp...@gmail.com> writes:
> 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. > It has been about 2 months since Nicholas' last comment. He may have been busy and occupied by other businesses, so I'm un-setting the owner. I would like to thank Nicholas for his valuable comments and suggestions. Meanwhile, as this RFS has been open for 9 months, I'd like to invite inputs from more DDs to get this sponsored before the freeze. TIA! > -- > Regards, > Xiyue Deng -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
