Re: GR: Change the resolution process (2021-11-25 revision)
On 2021-11-30 at 17:36, Kurt Roeckx wrote: > On Thu, Nov 25, 2021 at 07:25:45PM -0800, Russ Allbery wrote: >> 3. Minor changes to ballot options under point A.1.5 may not be made >>after or within 24 hours of the end of the discussion period unless >>the Project Secretary agrees the change does not alter the meaning >>of the ballot option and (if it would do so) warrants delaying the >>vote. The Project Secretary will allow 24 hours for objections >>after any such change before issuing the call for a vote. > > I suggest rewording this to avoid the negative, so remove the > "not", change the "unless" to "if". The same applies to some > of the other points. Speaking only for myself (and as someone not entitled to vote), I would find the result of this more confusing, less understandable, and harder to read - to such an extent that if I ran across it, I would be inclined to suggest rephrasing it to use the negative instead. If I'm parsing my own reaction correctly, the reason is that this would change this from having the prohibition on making such changes during that period be stated explicitly, to having it not be stated directly at all, but only implied in "the exception that proves the rule" fashion. At the very least, I think you'd need to use something like "if and only if" rather than just "if". More complicated rephrasings might produce better results; on that point, see below. > It's also unclear what the "after or within 24 hours" means. I parsed that (together with the rest of the phrase) as meaning that the prohibition on such minor changes takes effect 24 hours prior to the end of the discussion period, and lasts indefinitely thereafter. The reason is that all periods after the end of the discussion period are included by the clause "after the end of the discussion period", so the "within 24 hours of the end of the discussion period" clause can only be extending this backwards from the end, to cover the preceding 24 hours. If I've got that right, then perhaps something like "Minor changes to ballot options under point A.1.5 may only be made until the point 24 hours before the end of the discussion period, unless" might address both points above at once? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Draft proposal for resolution process changes
On 2021-09-28 at 11:44, Russ Allbery wrote: > Gard Spreemann writes: > >> Russ Allbery writes: > >>> A.2. Withdrawing ballot options: >>> >>> […] >>> >>> 4. The default option cannot be withdrawn. > >> This is the most minor of near-useless pedantic comments on my >> part, but A.2.4 seems redundant: If only the proposer of a ballot >> option may withdraw it (A.2.1), and the default option has no >> proposer (A.1.7), then we don't really need a separate rule saying >> that the default cannot be withdrawn. > > Yes, I completely agree there's no technical need for this. I > included it anyway because it felt like it added some clarity and > meant that the reader didn't have to chase the logic down through > several other provisions to be sure. There are a few other places > like this in the text (mostly around repeating phrases) where I erred > on the side of clarity rather than brevity. > > I can certainly change this if people would prefer. It's possible > that I overcorrected for how tricky I find it to interpret the > current wording. As a possibility to consider, what about folding this into A.1.7? That already states that the default option cannot be amended, which likewise would seem to follow from the fact that it has no proposer and thus no one to make or accept amendments. Something like "The default option has no proposer or sponsors, and as such, can neither be amended nor withdrawn." would seem to convey all aspects in one concise sentence - although it does have the downside that it would be referring to withdrawal prior to the section where withdrawal is discussed. (I'll note that I'm barely even a contributor, certainly not a DD, so my voice here has significantly less relevance than might be ideal for participation in such a discussion.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Nuance Regarding RMS
On 2021-04-01 at 15:06, Milan Zamazal wrote: >>>>>> "JS" == Jonas Smedegaard writes: > > JS> Question is, this being a process to compose a ballot for a > JS> vote: How to transform those observations into a text for the > JS> ballot? Or if that is absurd, how else to proceed (other than > JS> shrug and let the boting process continue disregarding those > JS> observations? > > I think “The Debian Project will not issue a public statement” and “None > of the above” are good enough ballot options for the purpose. And > definitely much better than voting about one’s weirdness or malice, > directly or indirectly. For whatever it may be worth, I parsed the original essay-mail in this thread as being not a starting point for a ballot option, but an attempt by one potential voter to convey his perspective on the issue to other potential voters, and thus to potentially affect how those others may choose to vote when the time to do so comes. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
On 2019-12-05 at 04:34, Raphael Hertzog wrote: > Hi, > > On Mon, 02 Dec 2019, Guillem Jover wrote: > >> Reframing - >> >> Why have init systems become such a contentions and toxic issue? I >> mean yeah, it potentially integrates with many parts of the system, >> but we do have other components in the distribution with multiple >> or non-portable implementations, where we have managed to handle >> them all just fine (at least w/o major conflict)? Say http servers, >> databases, etc., or Linux specific security frameworks such as SE >> Linux or AppArmor. We even have multiple implementations of things >> like shell interpreters, or awk. The exact same thing applies to >> hardware architectures, some of which have less popcon than say >> GNU/Hurd or GNU/kFreeBSD! > > It's easier to handle multiple alternatives for optional components. > You can have a Linux system without any security module or without an > HTTP server or database server. > > You can't have an OS without a kernel or without an init system. For > the kernel, we already made it clear that we are primarily about > Linux, both due to the name of our distribution and with the fact > that the release architectures. I certainly appreciate the non-Linux > ports and I'm generally in favor of welcoming those efforts under the > Debian umbrella as long as they don't impede the rest of the project > in any substantive way. > > For the init system, we have changed the default but it seems that in > the minds of many contributors, it should be considered an equal to > openrc or sysvinit and we should not fully embrace it so that it > remains equal to the other init systems. To me, it looks as if this entire thing is an outgrowth and/or another expression of something which I've seen - and, I think, sometimes pointed out - as far back as the original "should we change the default init system?" discussions: people don't have a shared understanding of what it means for an init system to be the default. At minimum, "X is the default" means "you will get X if you don't take any action to avoid doing so". All definitions I can think of seem to share that baseline. At something like maximum, "X is the default" could be read to mean "getting anything other than X is not expected to be possible". There is a lot of room in between those two, and I believe I've seen people who seem to be expecting it to mean many different things in that range. (Just offhand, I can't even tell what meaning you had in mind when you used the term in the last quoted paragraph above.) At least from a certain perspective, the various options presented in this GR - and some of the positions taken in discussion, which may not have become formal options - can be seen as advocating for various definitions of "default" within that range. It has been, and remains, my opinion that until we (preferably) reach agreement on what is meant by this term in the context of init systems, or (at least) bring the various definitions being used - if only implicitly - by different parties/factions/whatever into explicit view, we will not even be able to have fully meaningful discussions of the subject, let alone actually reach an agreement which might settle the larger init-system arguments. I've been hoping, every time this discussion comes up, that we would wind up having that explicit conversation about what "default" does or should mean in this context (although I haven't tried to speak up with that goal nearly as often as I've had the thought, because I'm not great at that type of advocacy and it usually seemed like doing so would be less likely to help than to make the situation worse). Unfortunately, as far as I can tell, that doesn't seem to have ever happened. This GR seems to be nearly as close as we've come, and it's still a layer or two of implicitness away from actually making it explicit. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: REISSUED CfV: General Resolution: Init system coupling
On 11/09/2014 at 05:26 AM, Jonathan Dowland wrote: > On Sun, Nov 09, 2014 at 04:27:21AM +0100, Michael Meskes wrote: > >> I'd assume he was referring to: >> >>> If my GR passes we will only have to have this conversation if >>> those who are outvoted do not respect the project's collective >>> decision. >> >>> If my GR fails I expect a series of bitter rearguard battles >>> over individual systemd dependencies. >> >> This to me reads like the threat Holger mentioned. And for the >> record, I was very surprised to this given the history of the >> decision. > > FWIW, I did not read this as a threat, or at least, I did not read it > as suggesting that Ian himself would participate in this bitter > rearguard action. I read this as meaning Ian suspected that unless > his GR was carried, various anti-systemd people would not be > mollified and their disagreement would percolate down to individual > packages and bugs, rather than being discussed (and potentially > addressed) at a project-wide level. As such, and I'm assuming good > faith on Ian's part here, I think Ian was trying to describe what he > thought was the likely outcome, and not specifically threaten to > behave in a particular way. Thank you. I've been trying to think of a way to clearly express that for some time now, ever since people first started to indicate that they thought this comment was a threat. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
(Responding quickly to only the part I think I can address well on short notice, without needing to spend a long time thinking it over.) On 11/02/2014 at 07:58 PM, Russ Allbery wrote: > The Wanderer writes: >> systemd-shim 8.2 and 7.1 do not list a dependency on systemd, or >> appear to invoke one indirectly; as far as I recall, no such >> dependency had previously been present, either. Attempting to >> install systemd-shim and remove systemd in a --dry-run does not >> complain. > > That's because the point of systemd-shim is to provide the services > that logind requires without running systemd as PID 1, so that > packages can then depend on logind without requiring systemd be PID > 1. That didn't require a direct dependency on systemd because that > dependency comes in via libpam-systemd or some other route in the > software using logind. > > In other words, the whole point of systemd-shim is to enable the use > of logind. It's not replacing it with something else. ...I'm confused. Assuming you're correct in your description of the purpose of systemd-shim (I could argue that the concept of the package could / should extend to providing "stub" implementations of the interfaces provided by the various services provided by systemd-the-project), then it seems obvious that systemd-shim must necessarily depend on having systemd-the-package installed, since otherwise logind itself would not be installed. However, you've presented this as an explanation of the fact that systemd-shim does not list a "Depends: systemd" - when in fact it would seem to require that systemd-shim *must* list such a dependency. This comes after I pointed out that the package does not list such a dependency, which comes after you (as far as I can tell) claimed that it had always listed such a dependency, which comes after I mentioned that the discussion in bug 765101 seemed to indicate that such an (explicit) dependency would be added. Leaving aside the unnecessarily confusing nomenclature which no one seems interested in trying to clear up even for colloquial use, I can't make any sense out of this. Could you try to explain it more clearly? (Not necessarily on-(this-)list, unless you think others might be interested. I'm on -user, -devel, -project, -policy, and -mentors, as well as here.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
On 10/28/2014 at 12:20 PM, Russ Allbery wrote: > The Wanderer writes: > >> What I'm thinking of is cases where upstream has decided to depend >> on functionality that is provided by one init system but not by >> others, without graceful runtime fallback - compile-time choices, >> essentially, where functionality is omitted if the init system is >> not present. I have had the impression that GNOME is one such >> upstream, to whatever extent it has not dropped support for >> non-systemd environments entirely. > > But that's not the same sort of thing at all. > > You were talking about how to package software that supports > multiple kernels or multiple architectures but with different > capabilities on those different kernels or architectures. We have > packaging tools to deal with that, yes. We have similar packaging > tools to deal with software that supports multiple init systems with > different capabilities. It's a mostly solved problem. Is it? I thought part of the problem is that there are packages whose upstream supports (or at least enables) compiling with / without integration to functionality provided by systemd, and which are provided in Debian only as compiled with that functionality enabled, with no alternative package which omits that functionality. I had the impression that GNOME was one such (set of) package(s). It seems unlikely to me that such exclusivity would occur if packaging for both in parallel (and handling dependencies on the parallel packages) were a "solved problem" in that way. Certainly I know of no functionality to make it easy or automated to provide such packages, comparable to e.g. the multiarch package labeling... > You're now talking about packages that *do not* support multiple > init systems at all, but instead rely on capabilities that are > specific to one init system. Actually, I'm talking both about software which has been (as you put it) "ported" to support multiple init systems and, separately, about software which has not. My idea was approximately that the former could be addressed by an analog of the multi-arch "parallel packages" model, with multiple binary packages from the same source package, and the latter could be addressed by "simply" having the package manager not 'see' a particular package as being available for installation unless the environment is such that the features are expected to be provided - a stronger version of a hard dependency. The latter of those two hypothetical approaches was based on what now appears to have been a mistaken impression about the way kernel-category dependencies are handled currently. How does software which requires the features of a particular kernel currently depend on having that particular kernel active? I would have expected it to be via a dependency on 'linux-image' or 'kfreebsd-image' or the like, but at a glance I don't see my current linux-image-* package providing any such virtual package, and offhand I don't know of any kernel-dependent packages except for systemd - which does not obviously appear to express any kernel-related dependency. If such software effectively does not so depend, instead choosing to simply fail at runtime, that would be a somewhat odd design choice but might be one we could emulate for init systems... I'm not sure I'd support that approach even if so, though. >> And that's entirely my point: something which depends on a feature >> provided by a kernel or an architecture, such that it won't build / >> run properly on anything that doesn't provide that feature, can be >> packaged either so as to be compiled with support for the feature >> in environments which provide it and without support for it in >> environments which don't or so as to be available (package visible >> to the package manager) in environments where the feature is >> available and not in ones where it is not - but something which >> depends on a feature provided by an init system cannot AFAIK be >> packaged in a comparably varying way, with the current packaging >> infrastructure. > > This is a bad comparison. You're comparing software that has been > ported to multiple architectures (with some degredation of > capabilities) to software that has not been ported to multiple init > systems at all. You can't do that and arrive at any meaningful > conclusions; you're comparing apples to oranges. I thought I'd adequately allowed for both sides of that? The "software that has been ported" would fall under "can be packaged so as to be compiled with / without support", and the "software that has not been ported" would fall under "can be packaged
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
(I wonder about the extent to which this remains on-topic... I didn't hesitate about my previous post, since it was relatively brief and addressed what I thought was an important and relevant single point, but this is considerably longer and gets rather farther afield.) On 10/27/2014 at 11:54 PM, Russ Allbery wrote: > The Wanderer writes: > >> Just as a note, one difference here is that there is support in >> the archive and package-distribution mechanisms for having multiple >> versions of a package for different architectures or (I think?) >> kernels, so that you can build a version with some optional >> features for one architecture / kernel but a version without those >> optional features on another - but there is no such support for >> having multiple versions of a package for different init systems. > >> You can only have one architecture, only one kernel, and only one >> init system active at any given time. The archive and its >> infrastructure recognizes this for architectures and (I think) >> kernels, and supports special handling for them to avoid or work >> around problems which would (or easily could) otherwise be present. >> The archive and its infrastructure do not presently recognize this >> or provide such support for init systems; as such, no such >> workarounds are available. > > *looks at his packages that support systemd, upstart, and sysvinit* > I think you're confused about where the hard parts of this process > are. > > It's often easier to support multiple init systems in a package than > supporting multiple architectures or multiple kernels. It's > certainly nothing that tremendously difficult to do. What sort of packages are these, and what sort of support is involved? What I'm thinking of is cases where upstream has decided to depend on functionality that is provided by one init system but not by others, without graceful runtime fallback - compile-time choices, essentially, where functionality is omitted if the init system is not present. I have had the impression that GNOME is one such upstream, to whatever extent it has not dropped support for non-systemd environments entirely. If adding support for other init systems to such packages (so that they do not assume the presence of certain functionality in the environment, but either can provide it themselves, or will simply fall back to not providing certain features if that functionality is not present) is not difficult, then that's certainly a good thing - but that is not the impression I've gotten from the comments thus far. My comments were pretty much not at all about init scripts or their equivalents, which after all are only about starting or stopping whatever "service" is in question, but only about functionality provided to other processes by the running init system. > The packages that are causing all the controversy at the moment > aren't created by some sort of archive limitations, or even by a > breakdown of this process. The problem, rather, is that only one > init system (or at least one init system's infrastructure; I'm > counting logind as part of systemd here) supports some decidedly > non-trivial features that those packages use, and no one has provided > a supported implementation of those features for other init systems. > In other words, they're very much akin to ZFS on FreeBSD. And that's entirely my point: something which depends on a feature provided by a kernel or an architecture, such that it won't build / run properly on anything that doesn't provide that feature, can be packaged either so as to be compiled with support for the feature in environments which provide it and without support for it in environments which don't or so as to be available (package visible to the package manager) in environments where the feature is available and not in ones where it is not - but something which depends on a feature provided by an init system cannot AFAIK be packaged in a comparably varying way, with the current packaging infrastructure. I am sort-of attempting to propose a different model for expressing the dependency of these upstreams (and the resulting packages) on the functionality provided by one particular init system, one which might be able to more easily allow "package with dependency and with matching functionality" to coexist with "package without dependency and without matching functionality". > But we already have a reasonable workaround in the form of getting > the systemd component to work under sysvinit. That's a matter of providing the functionality under other init systems. I am talking about making it (relatively) easy to provide parallel versions of the package which work when the functionality is not available i
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
On 10/27/2014 at 10:29 PM, Anthony Towns wrote: > On 28 October 2014 02:36, Steve Langasek wrote: >>> It's clear that many who support systemd balk at the idea they >>> might not be allowed to leverage systemd-specific features in >>> Debian. > > I'm not sure I've seen people seriously proposing preventing people > from leveraging systemd-specific features. Are they? That seems like > a bad idea -- I wouldn't expect people to be forbidden from letting > their packages take advantage of powerpc or freebsd specific > features, just because I won't be able to use them on inux/amd64. Just as a note, one difference here is that there is support in the archive and package-distribution mechanisms for having multiple versions of a package for different architectures or (I think?) kernels, so that you can build a version with some optional features for one architecture / kernel but a version without those optional features on another - but there is no such support for having multiple versions of a package for different init systems. You can only have one architecture, only one kernel, and only one init system active at any given time. The archive and its infrastructure recognizes this for architectures and (I think) kernels, and supports special handling for them to avoid or work around problems which would (or easily could) otherwise be present. The archive and its infrastructure do not presently recognize this or provide such support for init systems; as such, no such workarounds are available. It seems possible that some of the problems potentially / arguably introduced by having features provided by only a subset of available init systems could be avoided or resolved by having multiple package versions for different init systems, much as we already have for different architectures and in some cases kernels. However, I'm not at all sure that it's clear that the benefit of having such would be worth the trouble of setting it up and maintaining it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On 10/18/2014 at 06:21 AM, Luca Falavigna wrote: > Dear fellow Developers, > > I would like to propose the following amendment proposal, and I > hereby call for seconds. > > > > ** Begin Alternative Proposal ** > 2. Specific init systems as PID 1 > > Debian packages may require a specific init system to be executed as > PID 1 if their maintainers consider this a requisite for its proper > operation by clearly mark this in package descriptions and/or by > adding dependencies in order to enforce this; and no patches or other > derived works exist in order to support other init systems in such a > way to render software usable to the same extent. One potential problem which I see with this: Imagine a scenario in which this GR had not been raised, and jessie had been released with systemd as default init system, and so forth. Imagine that the maintainer of package foo decides, as they are entitled to do under this proposal, that 'foo requires upstart for proper operation' (choosing upstart just as an example here), and adds a dependency on a hypothetical set-upstart-as-PID-1 package. Imagine then that someone who is running happily with systemd as PID 1 decides to install package foo. This would cause their system to be switched from systemd as PID 1 to upstart as PID 1, comparably to what now happens when someone who is not running with systemd as PID 1 installs a package which depends on systemd-sysv. It seems unthinkable to me that this would not be considered a problem; as far as I can tell, the only reason that the dependency-based switch to systemd under the current arrangement is potentially not considered a problem is that systemd has been designated as the default init system for jessie, which would not be true of upstart in this hypothetical case. Yet under this proposal, the package maintainers would be fully entitled to do exactly the things which necessarily result in this problematic scenario. According to my best assessment at present, that type of scenario seems to be exactly (or at least a significant part of) what the original GR proposal is trying to prevent - in a broader form, which is not specific to any particular pair of init systems. This proposal would not prevent that scenario, and indeed would seem to enshrine it as something which is fully allowed. The only way I can see to avoid that scenario without a rule that no package may depend on a particular init system being PID 1 would be to add functionality to apt and/or dpkg to detect (probably at dependency-resolution time) when a package install triggered via a dependency will trigger a change of init system, and *reject* the install - requiring that the user / sysadmin specify the new-init-system package explicitly, rather than as a dependency, in order to trigger the actual init-system change. I don't know how difficult that would be to implement, but I imagine that it would be at least mildly controversial as well, although probably much less so than either systemd has been or this GR is proving to be. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
