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. -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
