Control: owner -1 ! Control: tag -1 +moreinfo Xiyue Deng <manp...@gmail.com> writes:
> Xiyue Deng <manp...@gmail.com> writes: >> 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: >>>>>>> Nicholas D Steeves <s...@debian.org> writes: >>>>>>>> Xiyue Deng <manp...@gmail.com> writes: >>>>> >>>> >>>> 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. >>> This has nothing to do with "handling", workflow, nor gbp. Yes, non-native source package is the key term. More on this later. >>>> 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. Thanks. They don't need numbers if they have context btw, and thank you, you last email was better. >>>> 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. Are you sure about that? Merging from a dgit remote may introduce dgit-specific changes (patches-applied vs patches unapplied, different patch handling, other changes made by someone other than you, etc.) >>>>>> - 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 Ok, you've moved the words around. You're a DM now and need to cultivate understanding; this isn't a workflow issue, gbp/dgit issue, "handling" issue, pedantic style issue, etc.. Both cases of changelog:L11 demonstrate that the author of this line doesn't understand what a non-native source package is, nor how copyright works in a non-native source package. Skimming policy will be insufficient; if a close read of Policy doesn't provide enough data logic your way through this then it may be necessary to consult Developer's Reference or other documentation. >>>>>>> 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) Did you contribute to that discussion? >>>>>> 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. Are you addressing the lintian case with that response? To be clear, I mean if a person says "Don't open that door, the room is filled with toxic gas". Did that person speak a warning or a suggestion? Also, I hope you see why the reply you wrote is highly problematic to the toxic gas case. > 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. I've been waiting for you to answer the questions that have thus far been evaded or left unaddressed. Regards, Nicholas
signature.asc
Description: PGP signature
