On Fri, 22 Nov 2019 08:01:37 -0500, Sam Hartman wrote: > >>>>> "gregor" == gregor herrmann <gregoa@debian.org> writes: > gregor> This contradicts the spirit, culture, and conventions around > gregor> NMUs which are prevalent in Debian for at least ten years > gregor> and are written down in DevRef 5.11.1. > > I actually think that being able to NMU a package to add init system > support is entirely consistent with what debref says about NMUs. > It sounds like you're worried that I'm trying to lessen the categories > of things that can be NMUed. > Or that I'm tieing NMU to bug sevirity. > I'm not trying to do that either. > I'm trying to recommend a bug severity and emphasize that NMUs are > appropriate. Thanks for the clarification. > I'd appreciate help in achieving these goals without undermining the > text in debref. I think the main problem is actually that you try to write down NMU rules in a GR; where they do not belong, as the NMU guidelines develop in practice and are reflected in the process of updating DevRef. From a different point of view: If you are just referring to the existing NMU guidelines, why do you mention them in proposal 1a but not in proposal 2 and 3? > I think it is important to emphasize that these bugs can be NMUed in > this choice. Why? I mean, why are you treating these bugs differently than any other of the gazillions of bugs, or more to the core of this GR, differently from missing systemd service units in proposal 2 etc.? > Since that is already consistent with the tradition you > cite, I'm not seeing the problem. The problem in my opinion is mostly that this aspect doesn't belong into this (or any) GR. > But if you can suggest language that > continues to emphasize that NMUs are appropriate in this situation > without doing damage to that tradition, I would greatly appreciate it. I think Holger's proposal goes in the right direction, although I would go a step further and say, leave it out and maybe mention "BTW, we have NMUs for bugs" in an appendix -- for all options. > I do not support removing the statement about NMUs under the grounds > that it is obvious. Fine with me; personally I will rank all options talking about NMUs below FD. And taffit has captured my thoughts very good when he writes: On Fri, 22 Nov 2019 06:06:59 -1000, David Prévot wrote: > By doing that, this choice de facto overrides the currently documented > (and working) NMU workflow and practices. > I believe it opens a can of worms. It sets on stone an NMU workflow, > making it impossible to let the rule evolve as it usually did. Worse, if > such things is accepted via GR, one will be able to argue later that > other NMU fixes are not acceptable (“the only NMU fix one can do is the > one the project agreed on with GR2019#1“). That's exactly what I oppose: Writing down NMU rules in a GR, even if they at the time of writing just represent the current culture and guidelines, will get into the way of adjusting them in the future. Maybe this also answers a bit your followup question to taffit: On Fri, 22 Nov 2019 12:40:47 -0500, Sam Hartman wrote: > David> By doing that, this choice de facto overrides the currently > David> documented (and working) NMU workflow and practices. > In what way? > How does it override them? > To override them it needs to say something inconsistent with these > practices. > What is inconsistent between what the resolution says and the existing > practices. Currently probably nothing. But NMU guidelines might (want to) change and then the GR is still there. And then they might contradict each other. - I just don't see any advantage and potential disadvantages. On a more general point (answering your other question on potentially withdrawing your proposal 1(a)): Yes, I think as we have Ian's and Dmitry's options I don't see any huge value in keeping hartmans1a on the ballot. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: trio infernal: desafinado
Attachment:
signature.asc
Description: Digital Signature