Re: Choice Hartmans1a
Hi. You provided a diff to the text on the website, which hadn't been updated with choice hartmans1A. Attached is the patch I actually applied, which I believe is consistent with the spirit of your changes. diff --git a/init-system-gr b/init-system-gr index dade7d0..f2ee7f2 100644 --- a/init-system-gr +++ b/init-system-gr @@ -2,7 +2,7 @@ -Choice hartmans1A: Init deversity is Important and NMUable +Choice hartmans1A: Init deversity is Important The project issues the following statement describing our current position on Init systems, Init system diversity, and the use of @@ -16,9 +16,10 @@ Being able to run Debian systems with init systems other than systemd continues to be something that the project values. Every package should work with pid1 != systemd, unless it was designed by upstream to work exclusively with systemd and no support for running without -systemd is available. It is a important bug (although not a serious one) when -packages should work without systemd but they do not. Developers may -perform non-maintainer uploads to fix these bugs. +systemd is available. It is a important bug (although not a serious +one) when packages should work without systemd but they do not. +According to the NMU guidelines, developers may perform non-maintainer +uploads to fix these bugs. Software is not to be considered to be designed by upstream to work exclusively with systemd merely because upstream does not provide,
Re: Choice Hartmans1a
> "gregor" == gregor herrmann writes: gregor> Thanks for the clarification. I am going to accept Holger's proposed changes and post this as an accepted amendment to Proposal A. >> I'd appreciate help in achieving these goals without undermining >> the text in debref. gregor> I think the main problem is actually that you try to write gregor> down NMU rules in a GR; where they do not belong, as the NMU gregor> guidelines develop in practice and are reflected in the gregor> process of updating DevRef. We're not in agreement on what belongs in a GR, especially in this GR. I wonder if you believe that a GR sets long-running policy that would be hard to overturn. Yes, a GR can do that. But This choice on this GR doesn't do that. Quoting in part: >The project issues the following statement describing our current >position on Init systems, Init system diversity, and the use of >systemd facilities. This statement describes the position of the >project at the time it is adopted. That position may evolve as time >passes without the need to resort to future general resolutions. That is, this describes where we are today. That can move along over time. And yes, people can point back to the GR result and use that as a justification. For example if choice hartmans1A won the vote, and the next day someone proposed we throw out sysvinit, it would be reasonable to argue that it was exceedingly unlikely the project had changed its mind in a day. Even two years down the road, if someone proposed throwing out sysvinit, you would presumably ask them to demonstrate a consensus to do so or significant changed circumstances before seriously considering the proposal. But even a month later if the NMU guidelines had changed, arguing that outdated text in the GR about NMUs no longer applied would be entirely reasonable. This GR is about systemd and init systems, not NMU guidelines. If it touches on NMU guidelines in an auxiliary manner, it's reasonable to assume it does not stop the evolution of those guidelines. Now, if choice hartmans1a passes, it would be reasonable to discuss the impact on the ability to fix init system related bugs in a discussion of NMU guidelines. I think that's fine and reasonable. You wouldn't be obligated to keep things working the same, but someone should argue you could, just as they could argue in favor of the status quo in a number of ways. Why do I wantto emphasize that you can NMU in choice hartmans1a? Because one of the thing that various proponents of init diversity have requested is the ability to do work without people blocking them. Being able to NMU gives a significant part of that, so I want to emphasize how the option meets (or partially meets depending on your opinion) that desire.
Re: Choice Hartmans1a
On Fri, 22 Nov 2019 08:01:37 -0500, Sam Hartman wrote: > > "gregor" == gregor herrmann 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 signature.asc Description: Digital Signature
Re: Choice Hartmans1a
> "David" == David Prévot writes: David> Le 22/11/2019 à 03:01, Sam Hartman a écrit : >> I think it is important to emphasize that these bugs can be NMUed >> in this choice. 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. --Sam
Re: Choice Hartmans1a
Le 22/11/2019 à 03:01, Sam Hartman a écrit : > I think it is important to emphasize that these bugs can be NMUed in > this choice. 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“). There were other concerns raised about RCness and severity of bugs. Given the length of many of the proposed options, I wonder how many of those counterproductive corner cases will we be able to find in the next twenty years. In the past, at least GR2007#2 (the only GR I was able to find that evokes NMU) was worded as “the initial policy [on matter X is …]”, making it possible to let things evolve without the need to endure another GR process. GR2007#2: https://www.debian.org/vote/2007/vote_003 Regards David signature.asc Description: OpenPGP digital signature
Re: Choice Hartmans1a
On Fri, Nov 22, 2019 at 08:01:37AM -0500, Sam Hartman wrote: > I'd appreciate help in achieving these goals without undermining the > text in debref. Choice 1: Init deversity is Important and NMUable -> Choice 1: Init diversity is Important and However, adding an init script to such a package is appropriate for a non-maintainer upload. -> This also means, that according to the NMU guidelines, adding an init script to such a package is appropriate for a non-maintainer upload. ...and non-maintainer uploads to add that support are appropriate. -> ...and non-maintainer uploads following the NMU guidelines to add that support are appropriate. on the text on https://www.debian.org/vote/2019/vote_002#proposera with Last Modified: Thu, Nov 21 17:08:51 UTC 2019 Last Built: Thu, Nov 2117:09:59 UTC 2019 -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Choice Hartmans1a
> "gregor" == gregor herrmann writes: gregor> On Thu, 21 Nov 2019 13:58:09 -0500, Sam Hartman wrote: >> Choice hartmans1A: Init deversity is Important and NMUable gregor> […] >> Developers may perform non-maintainer uploads to fix these bugs. 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. I'd appreciate help in achieving these goals without undermining the text in debref. The text does not currently tie the ability to NMU to bug severity. Important bugs are valuable for among other reasons being suitable for inclusion in a stable release update. I think it is important to emphasize that these bugs can be NMUed in this choice. Since that is already consistent with the tradition you cite, I'm not seeing the problem. 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 do not support removing the statement about NMUs under the grounds that it is obvious.
Re: Choice Hartmans1a
[2019-11-21 13:58] Sam Hartman > Choice hartmans1A: Init deversity is Important and NMUable > [...] > Developers may > perform non-maintainer uploads to fix these bugs. As was already pointed, this is useless. Developers already can NMU any bug. > modification of Policy to adopt systemd facilities instead of > existing approaches is discouraged unless an equivalent implementation > of that facility is available for other init systems. What is "discouraged"? Who and how decides when discouraged behaviour is acceptable? I think, should this option win, scrimishes and lawyering will continue. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Re: Choice Hartmans1a
On 21/11/19 at 13:58 -0500, Sam Hartman wrote: > It is a important bug (although not a serious one) when > packages should work without systemd but they do not. Developers may > perform non-maintainer uploads to fix these bugs. I think that it would be better to leave details of the BTS out of this GR. After all, we could decide that bugs are ranked from 0 to 5, with 0 being the "release-critical" level. This wording writes in stone that we have an "important" bug severity. Also, the release team has the responsibility to decide which bugs are release-critical, what this statement does should be to say clearly that the bug makes the package unsuitable for release (or not), not just say something about its severity. How about something like: It is a bug when packages should work without systemd but they do not, but that bug is not release-critical (it does not make the affected package unsuitable for release). Developers may perform non-maintainer uploads to fix these bugs. Lucas
Re: Choice Hartmans1a
On Thu, 21 Nov 2019 13:58:09 -0500, Sam Hartman wrote: > Choice hartmans1A: Init deversity is Important and NMUable […] > Developers may > perform non-maintainer uploads to fix these bugs. This contradicts the spirit, culture, and conventions around NMUs which are prevalent in Debian for at least ten years and are written down in DevRef 5.11.1. NMUs can happen for any package, for any bug, at any time, and are not tied to any bugs types, bug severities, or permissions from GR outcomes. Obviously it makes sense to follow the conventions from DevRef; the text there explicitly also mentions wishlist bugs, and differentiates between bug severities only in the choice of the recommended DELAYED queue. Inventing NMUability rules tied to bug severities in a GR seems counterproductive to me. 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: Kurt Ostbahn & Die Kombo: Ollas wa so afoch signature.asc Description: Digital Signature
