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.
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? Congrats on DM, by the way! 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. >> 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. 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. >> - 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. >> 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." >> 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 :) Regards, Nicholas
signature.asc
Description: PGP signature
