Control: noowner -1 Xiyue Deng <manp...@gmail.com> writes:
> Xiyue Deng <manp...@gmail.com> writes: > >> Hi Nicholas, >> >> (Did I just find a way to reach you reliably?) >> >> Nicholas D Steeves <s...@debian.org> writes: >> >>> 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. >>> >> >> I think different people work in different ways. If you like this way >> then good. >> >>>>>>> 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.) >>> >> >> Yes, I'm fairly sure. As I mentioned, I only use "dgit sbuild" to build >> the package, which ensures that the tree is not dirty (non uncommitted >> changes), which git-buildpackage doesn't check by default. All other >> handling follows the normal gbp workflow. The other changes you >> mentioned that could potentially happen when using dgit is not being >> performed when handling this package. >> >>>>>>>>> - 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. >>> >> >> Sorry you lost me here. "changelog:L11" records a fact: upstream >> updated their license from GPL-2+ to GPL-3+ in 2022. This does not >> reflect any of my understanding: all I did is to document this fact. >> >> If you can clearly state what you think is wrong instead of picking on >> intellectual level differences, it would help both of us. >> >>> 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. >>> >> >> I think we are talking in circles: I've pointed out the policy sections >> (4.5, plus 12.5 which 4.5 referenced) that I think are relevant and >> don't see a clear issue in my wording. I think we can make better >> progress if you show me which section you think suggests that I'm doing >> it wrong. >> >>>>>>>>>> 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. >>>>>>>>>v >>>>>>>>> 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? >>> >> >> If you meant Bug#1001458, no, I didn't. And I think that's outside of >> the scope of this RFS. >> >>>>>>>>> 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? >> >> Yes, I gave an example that I think is more analog to the severity of >> the lintian warning, that it is acceptable in certain cases. Similarly >> this case, I think using filenamemangle is better because it provides a >> consistent behavior on package name transformation and is shared with >> the team which is better for maintainability compared to a local >> configuration file. This is also the reason given in Bug#1001458, if >> you have read that. >> >>> 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. >>> >> >> Now that if you insist on me replying to your metaphor, I would say your >> metaphor does not align with my understanding of error vs. warning >> vs. suggestion. If it's really "a room filled with toxic gas", then >> it's an error, because it's lethal. A warning would be like "a room >> filled with fart", it's unpleasant, but does not do much harm to your >> health. A suggestion would then be "a room lightly stink and could use >> some air refresher". >> >> To summarize, my understanding of errors vs warnings vs suggestions are >> errors should be fixed, while warnings and suggestions are better to be >> fixed but can be tolerable in certain cases. >> >> Anyway, I think we are starting to digress. Your original question was >> "what do you think is the optimal solution for web-mode", and my answer >> is "to leave it as-is" as this specific lintian warning is >> controversial. >> >> (Also keep in mind that I'm not a native English speaker. If you buried >> some other meaning in your metaphor then I don't get it. You would have >> to state it explicitly.) >> >>>> 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. >>> >> >> Sorry, but I think I have replied to all of your comments in my mail in >> last November (maybe some of the answers do not meet your standard, but >> I don't think I missed any). I have also sent a ping two weeks ago >> asking for more comments and received no reply, a.k.a. had been evaded >> or left unaddressed (well until now that was). >> >>> Regards, >>> Nicholas >> >> -- >> Regards, >> Xiyue Deng > > Ping for more comments. > Haven't received more inputs from Nicholas for another few weeks. I'm marking this RFS as no owner again. I want to thank Nicholas again for his comments which helped improved the packaging. Meanwhile I'd like to invite more audience for reviewing and potentially sponsoring this RFS in hope that it can make it to Trixie. TIA. > -- > Regards, > Xiyue Deng -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
