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
signature.asc
Description: PGP signature
