Has the asset tracking GR been reviewed by a lawyer
Hi. I'll admit that I've been rather out of the loop of late, but I do try to at least research GRs and make as informed of a decision as I can. I was unable to find any legal review of the proposed changes to the constitution. The idea of a project associated with a single non-profit for financial and legal matters is fairly well established: there is Debian and SPI, the IETf and ISOC, various arrangements involving the BSDs and a number of other things I'm aware of. Sometimes it works better than others--the projects with lots of money tend to have non-profits that are fairly organized, while projects with less money often do not enjoy as much organization. However, I'm concerned that the model we propose moving to may be much more dubious from a legal standpoint. Basically I'm not sure, and without a legal review I'm sure I can't support it. Has such a review happened? If so, is it public? If not public, can we at least know who did the review and have an assertion that they were happy with the proposed text? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is Choice 2 about
>>>>> "Lucas" == Lucas Nussbaum writes: TL;DR: Choice 2 is about valuing eventual alternatives to systemd, but believing sysvinit is a distraction in achieving that. It's also potentially a compromise for people who want to send some but not all of the init diversity work to downstreams. This message contains: * Response to the orthogonality argument * How do you get to choice 2 * What might happen if choice 2 passes. Orthogonality = Lucas> Hi, Lucas> On 07/11/19 at 13:04 -0500, Sam Hartman wrote: >> >> Choice 2: systemd but we Support Exploring Alternatives >> Lucas> What I'm concerned about is that the proposed GR is Lucas> conflating two different questions that are not completely Lucas> orthogonal, but quite orthogonal: - whether init scripts Lucas> must/should/may be included when there's already a service Lucas> unit - whether exploring elogind support should be supported Lucas> by Debian Maybe it might be better to unfold the possible Lucas> combinations that make sense in the list of options. Rather, I'd say that it has become quite apparent over the years that when discussing init systems, we cannot even come to consensus on the questions, much less the answers. The TC spent a great deal of time and pain trying to come to consensus on the question and ultimately failed to do even that. I haven't even tried. The world view and set of questions that leads to each of the choices I presented is slightly different. And, as you point out, choice 2 makes this more apparent than the other choices. See Simon Richter's messages for a demonstration of exactly how far the divergence on what questions to answer can get even in the current discussion. Getting to Choice 2: Here's a profile of someone who might support choice 2. You are concerned about some aspects of systemd. Perhaps it is just that you're concerned about a mono culture. Perhaps you're concerned that systemd includes modules that are more tightly integrated than you'd like; you would prefer something split into more components. However, you don't think sysvinit is the answer or is an important point along the path to finding that answer. We don't have an answer besides systemd today, but you hope Debian will be part of a laboratory that helps us develop such an answer. You probably see the value of service units over init scripts. Perhaps you want something even better long term, perhaps you think service units would be fine if it was something other than systemd that interpreted them. You might think that any future init system will interpret service units and possibly something new, *not* init scripts. Choice 2 is about the project being willing to spend the effort to integrate technologies that provide alternatives to some aspects of systemd. The work of developing such technologies would of course fall on the shoulders of people wanting to see them exist. Leaf package maintainers would get to choose whether supporting such an alternative made sense for their packages. However, sometimes integrating such technologies impacts other shared infrastructure, including systemd itself. If this is something the project cares about, we'd need to find people willing to follow discussions, review patches, etc enough that the integration that touches shared infrastructure could happen. It doesn't mean that people would need to adopt broken integrations or integrations that reduced stability for people using the default configuration; they would just need to provide reasonable review in a timely manner and work to come up with designs that would meet objections. The technology where this has been most apparent in Debian recently is Elogind (and previoustly systemd-shim). Various other technologies in this space have been theorized on debian-devel including support for .timer units not in systemd, code to turn .service units into something else, non-systemd support for sysusers files. What Happens if Choice 2 is Adopted === We'd need to check and make sure that the people in key roles like the release team and systemd maintainers that have been impacted by these sorts of integrations lately were comfortable providing timely review and engaging constructively to resolve objections they raised. If not, then we'd need to find additional developers willing to help with those efforts. It may well be that by the time the vote concludes, the existing integration issues I'm aware of will be resolved. In terms of sysvinit support. It might be that things would look a lot like choice 1. Maintainers are not required to provide init scripts, but they still may do so. And at least in cases where an init script can be provided with a working autopkgtest and the init script i
Re: [draft] Draft text on Init Systems GR
tement of the day (4.1 (5)) or to make a decision under TC power (4.1 (4)). A statement of the day is less forceful; it doesn't have any formal power. It lets us understand consensus, but allows maintainers and policy editors to interpret what we say. If it turns out we missed some key issue in our discussion, they can even come back to debian-devel and raise the issue. If we used TC power, we'd need to decide which TC power to use. Presumably you'd be thinking of 6.1.1 (setting technical policy). I guess you could be talking about 6.1 (5: offering advice), but that's so close to a statement of the day that it doesn't make sense to me. Setting policy requires us to get a lot more precise and to get the details right in a way that seems hard for a GR. Also, using power under 4.1 (4) requires a 2:1 majority, where as simply making a statement of the day is a simple majority. I think that if we know the views of the project, the rest will fall into place in policy and in other areas. So I prefer to use the smallest hammer that will accomplish that goal. Choice 1: RC or Not === >>>>> "Wouter" == Wouter Verhelst writes: >> Policy editors are requested to amend policy; including a service >> unit without an init script is appropriate for a non-maintainer >> upload but should no longer be an RC bug. Wouter> If this choice wins, then why should it not be an RC bug to Wouter> not have an init script? That doesn't seem to make sense. In current policy, it's a normal bug to not include an automated way of starting a daemon at all. So, no init script, no systemd unit is a normal bug. But if you provide a systemd unit without a init script, that is an RC bug. While I did not get review of the final text from my init diversity reviewer, I did discuss this particular point with a number of people who favor init diversity. Overwhelmingly they were asking for the ability to be able to work on init diversity. They weren't talking about blocking other people's work or about stopping people from using systemd. They just wanted their patches reviewed in a timely manner, wanted to be able to decide what was good enough for sysvinit users, and wanted patches that met that bar (and didn't introduce other problems) to be accepted. The current policy is very much perceived as the init diversity crowd trying to hold the RC hammer over others. Multiple people were either surprised that policy reads as it does today, or that the policy editors couldn't get consensus to make this change on their own. I was prepared to have two versions of choice 1: one with no init script RC, and the current version. But at least in the people I talked to, I wasn't seeing a strong enough desire for the init script RC option. Holger> On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote: >> version 2330c05afa4 >> Choice 3: systemd without Diversity as a Priority Holger> [...] Choice 3 Title == Holger> a.) 'systemd without diversity as a priority' sounds like Holger> systemd is against diversity. I think this is borderline Holger> insulting. So I expect this will attract someone proposing Holger> another option called 'Embrace the future (*) and a modern Holger> init system' or such. *) or 'Embrace new technologies...' The systemd maintainers I ran the text by didn't complain about the title. Please speak up if you find the current title insulting toward systemd. I'm taking holger's current wording as a potential concern, not as something that he specifically finds insulting himself. Systemd Features Beyond Init Holger> On top of all of this, systemd provides much more features Holger> than unit files as the thread on -devel showed. There is no Holger> word about these technologies in this GR proposal. I think Holger> that's a flaw in this proposal. This proposal actually does speak to that issue. Obviously, the policy process may adopt limits on systemd technologies we use, and nothing in this proposal stops people from working to form a consensus on such a limit. But absent limits in policy, maintainers can generally use any systemd feature they like that the systemd maintainers enable in our builds. The question is wether maintainers need to provide non-systemd alternatives when they use such a feature. This proposal does speak to that choice. Choice 2 and 3 say that individual maintainers may include alternatives for individual systemd features if they choose. That may is intended to be my permissive: my reading of choice 2 and 3 is that it is not a bug to use a systemd feature without an alternative.
Re: [draft] Draft text on Init Systems GR
> "Wouter" == Wouter Verhelst writes: Wouter> Oh, right. Okay. I suppose that makes sense; the nbd-client Wouter> init script hasn't been touched since I wrote the nbd-client Wouter> systemd unit, and so I can't really guarantee that it will Wouter> work very well anymore. Wouter> I guess I was misunderstanding what Sam was writing Wouter> initially; I thought he just meant that "if you do early Wouter> boot, then we don't care about other init systems", which Wouter> seems like it would make the whole point moot. Wouter> Perhaps Wouter> rather than that, the GR should say something like: Wouter> "Due to the higher level of complexity inherent to Wouter> early-boot services, it is expected that the init scripts Wouter> (or equivalent) for services initialized during early boot Wouter> be maintained by the maintainers of the init system in Wouter> question, rather than by the maintainers of the service's Wouter> package" I like this sentence, and if we get significant support from those who favor choice 1, I would accept that amendment. Meanwhile, I think I can go as far as >Policy notes that early boot services like those started from >/etc/rcS.d may be tied closely to the init system in use and thus may >need to be handled differently for each init system well within the spirit of the current choice 1. I'd definitely like to resolve this ambiguity. All I'm trying to do is accurately summarize policy/our thinking on this issue in that sentence. That sentence is not even intended to make any changes, but calling out this point was important to Martin.
Finding Seconds and Alternate Choices
> "Bernd" == Bernd Zeimetz writes: Bernd> On 2019-11-12 18:56, Russ Allbery wrote: >> "Alexander E. Patrakov" writes: >> >>> I think that one choice is missing here. Could you please >>> include something like this, just to see how many people are >>> THAT radical? P.S. myself, I wouldn't vote for this even if I >>> had a vote. >> >>> Choice 4: systemd without Diversity at all >> >> Including options in a GR that no one supports is a waste of >> everyone's time and mental energy. Bernd> How do you know that no one supports that? I'd second that Bernd> and I'm sure there are many more out there who would do the Bernd> same. Imho all other options are wasted time at the end. In part because you hadn't spoken up yet.:-) While there's been no formal proposal yet, now does seem like a great time to express interest in options that I didn't present and to see if seconds would be available when we get to the formal stage. Simon has started that. I hope that if there options you would support more than tho options discussed already, you would let us know.
Matthias's Choice 4
> "Matthias" == Matthias Klumpp writes: I'd like to understand how what you propose below differs from my choice 3. This is more or less along the lines of what I meant to propose with choice 3, and I'd like to understand what differences you see that matter to you. There's a reasonable possibility this can be consolidated with my choice 3. Matthias> So, something like this maybe? (adapted from Alexander Matthias> E. Patrakov's text): ``` Choice 4: Focus on systemd as Matthias> init system and features requiring it Matthias> The Debian project recognizes that systemd service units Matthias> are nowadays the preferred configuration for describing Matthias> how to start a daemon/service. Packages should include Matthias> service units. At the same time, the Debian project Matthias> acknowledges that maintainers and upstream developers are Matthias> often unable to provide high-quality (or any) support for Matthias> alternative init systems in their packages on their own Matthias> and can not or do not test that their packages work under Matthias> such init systems. It is not realistic to expect the Matthias> situation to improve, and Debian does not want to block Matthias> experimentation with new Linux-based technologies Matthias> developed under the systemd project umbrella or hinder Matthias> their adoption by requiring all other init systems to Matthias> support the same features as well (which may not even be Matthias> desired by those projects). Therefore, Debian should Matthias> focus on a polished experience with systemd as init system Matthias> as first priority. Other init systems will remain Matthias> available as long as there is enough interest by people to Matthias> maintain them. Package maintainers are encouraged to Matthias> accept patches to support non-systemd configurations, as Matthias> long as the changes do not impair the user experience when Matthias> systemd is available. Package maintainers may split out Matthias> support for alternative init systems into separate binary Matthias> packages. Maintainers of other init systems are encouraged Matthias> to test support for their configurations if the package Matthias> maintainer can not do it. Matthias> Debian is still committed to working with derivatives that Matthias> make different choices about init systems. ```
Re: Matthias's Choice 4
> "Holger" == Holger Levsen writes: Holger> On Wed, Nov 13, 2019 at 04:19:29PM +0100, Matthias Klumpp wrote: >> I think there are only two differences: [...] Holger> there's a third, the title. I really like Matthias's title. I'd like to take a crack at folding Matthias's title and more emphasis that systemd is more than just an init system into choice 3. I don't know that we need all the verbosity of Matthias's text, but I like how it read and I'd like to see if we can take advantages of the work Alex and matthias did. --Sam
Re: Matthias's Choice 4
> "Russ" == Russ Allbery writes: Russ> Matthias Klumpp writes: >> However, I think it may be useful to highlight in the vote text >> somewhere that systemd is actually not just the init system, but >> a modular collection of different tools designed to work well >> together (many, but not all of them depending on systemd being >> PID 1), and that there may be benefit to the Debian operating >> system in deciding to adopt some of them, at least on the Linux >> ports. Russ> I strongly agree with this. Agreed. With the emphasis on "may be benefit". Russ> Right now, I think all three options that Sam put forward as a Russ> draft are insufficient because they aren't sufficiently clear Russ> on how we intend to handle the other plumbing and facilities Russ> that the systemd project is maintaining. I agree option 1 is less clear on this poin than I'd like. I'd love for someone to propose wording. I actually think options 2 and 3 are fairly clear on this point. I acknowledge more emphasis may be required. That is, I think the options state a position, but it's probably easy to read them and not realize that. * Options 2-3 say that maintainers may accept alternatives to systemd facilities. That means that it's reasonable to use facilities provided by systemd, and that it's not a bug if your package only works under systemd. People can submit patches if they wish you used less systemd facilities and you can consider those patches just as you would any patch. * both option 2-3 are silent on exactly what facilities we use. In general, maintainers get to use whatever facilities they like if there is not a project consensus against. * I don't think we're in a position to explicitly enumerate what facilities to use here in this GR, so I don't think there is a lot more to say. I don't think we want to say use all facilities with no limitations. As an example, I think we would need project level discussion to deprecate /etc/network/interfaces and move entirely to systemd-networkd. So, I think we want to leave open the possibility that we'll have discussions in policy or elsewhere about limitations on systemd facilities. * For a lot of the facilities, I don't think the project as a whole understands the facility enough to make a decision here. There are a couple like sysusers, socket activation and tmfiles where we probably do have enough understanding. In those cases, I think the default of "maintainers generally get to use whatever they like," is reasonable. But again, I wouldn't think we'd want to go so far as to preclude people proposing limitations.
Next Steps
I'm using the language of amendments and stuff even though I realize this is not formally correct. hi. My current plan to move forward based on discussion here is: * Update choice 1 to accept an amendment proposed by Martin: Correct an ambiguous sentence to say: > a package having a service unit but without an init script is no longer an > RC bug, but including an init script is appropriate for a non-maintainer > upload. * Update the early boot language per my discussion with Wouter * Change the title of choice 3 * In choice 1 integrate language similar to Russ's option B for non-init-system systemd features * In choice 2 integrate language similar to Russ's option C for non-init- systemd features * In choice 3 integrate language similar to Russ's option D for non-init systemd features. Russ is correct that I effectively proposed option C with choice 3, but my reading of the discussion is that people who prefer choice 3 are more likely to like option D than C. * Formally propose text as a GR I have no doubt I'll be accepting amendments and resetting the discussion timer at least once. However, I think we've more or less accomplished what we can do without an announcement to d-d-a. I think it's time to show something to the project as a whole and turn on the mechanisms for people to propose amendments and get seconds and all that. In terms of outstanding things: * I think those changes may effectively accept enough of Matthias proposal that he does not need to propose an amendment. If not, I'm very likely to be able to accept an amendment to integrate that. * I will not have accepted Dmitry's proposal either as a replacement for choice 1 or as a new option. I'd prefer that he collect seconds and control the wording of his proposal. * Choice 1 will still refer to current policy. I think that's OK but not great. I'd want to see people both supporting roughly what choice 1 does and supporting specific alternate text before making that change. * We will not have an choice on the ballot with Russ's option A regarding non-init systemd features. Dmitry's option would do that if it gets enough seconds. * There will not be an option like choice 3 with russ's option C (rather than Russ's option D). If we see k developers wanting that option I'd be happy to accept (or they could manage their own proposal). * I will not have accepted Simon's proposal either as a replacement for the entire ballot or as additional options. Again, I think Simon can collect seconds. If there are If it becomes clear that someone else is a better facilitator for one of the choices than me, I'm happy to turn that over. We can discuss logistics if that happens. One way would be for me to remove the choice from the proposal and for them to get seconds for an amendment. Timing: I'd like to do the above today. I don't know if it will happen; I'm in the middle of a fun project that is eating my brain at work.
Re: [draft] Draft text on Init Systems GR
Ian, first, thanks for a really great and constructive proposal. I'm assuming you plan to propose this as an amendment and get seconds. There's one area where I'm hoping you can come up with different wording, because at least for me, your current wording fails at being excellent to each other. >It is also for maintainers of > non-default init systems, and the surrounding community, to decide > what level of compromised functionality is acceptable to users of > non-default init systems. Every time I read that, I hear that the non-default init system community wants to be able to block other people's work until they are satisfied that the level of functionality is not too compromised. My understanding is that you are not actually trying to do that. So, if you are not trying to block other people, but instead are trying to avoid having non-default init users blocked can we find wording that is more clear? My emotional reaction to your current wording is really strong and negative. That's true even though I think I know what you're trying to say and have spent significant time trying to reduce my reaction. Even if you are trying to block other people's work, there is probably wording that at least for me doesn't get such a strong emotional response. signature.asc Description: PGP signature
Proposal: General Resolution on Init Systems and systemd Facilities
I'd like to propose the following resolution. Seconds are not required, but it would be valuable to get confirmation that the three choices contained in this proposal are worth having on the ballot. So, rather than seconding the proposal it would be useful if people would ack choices here they'd like to see on the ballot. Amendments will require seconds as usual. Timeline: I think that two weeks for discussion of this GR seems about right based on what's happened in the last week. The constitution allows the DPL to change the discussion period by up to a week. The discussion period is normally reset by the proposer accepting any amendment or making a modification to the proposal. If an amendment is accepted, I am likely to use that power such that the discussion period is the longer of two weeks from when the secretary sends mail to debian-devel-announce, or seven days past the time of the last amendment being accepted. In other words, if I accept an amendment in the next week, I'm likely to keep the total discussion period at two weeks. That said, if it looks like we need more time, I can always lengthen the discussion period. I do not see any circumstances under which I'd like to shorten the voting period for this proposal. version: d429a990a09 Changes since initial draft: * Clarify that packages may need to handle early boot in an init-system-specific manner in choice 1 * Clean up wording around the requested policy change in choice 1 * Adopt Russ's option B for choice 1 at least until we get clear direction from that community. * Adopt Russ's option C for choice 2. * Adopt something similar to Russ's option D for choice 3 * Add my name to choices to make life easier on the secretary as others get sufficient seconds. * Revise the title of choice 3 to avoid concerns that it is insulting to proponents of systemd. Using its power under Constitution section 4.1 (5), 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. The GR process remains available if the project needs a decision and cannot come to a consensus. Choice hartmans1: Affirm Init Diversity Being able to run Debian systems with init systems other than systemd continues to be something that the project values. With one exception, the Debian Project affirms the current policy on init scripts and starting daemons (policy 9.3.2, 9.11). Roughly, packages should include init scripts to start services that are included. Policy notes that early boot services like those started from /etc/rcS.d may be tied closely to the init system in use and thus may need to be handled differently for each init system. Init scripts are the lowest common denominator across all init systems. Packages may include support for init systems like systemd service units in addition to init scripts. Current policy makes it an RC bug to include a service unit without an init script. Policy editors are requested to amend policy; a package having a service unit but without an init script is no longer an RC bug, but including an init script is appropriate for a non-maintainer upload. Policy editors are requested to consider whether there are cases where removing an init script that used to be provided should be RC because it would break a system on upgrade. Once the community of users of an alternate init system have said that a solution is sufficiently functional for them, others should not generally second guess this determination. systemd unit files included in the package may use any systemd feature or service at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Init scripts must use only facilities common to all supported init systems in Debian and therefore may not use services that depend on systemd. Similarly, packages may freely use other systemd facilities such as timer units, subject to the above constraints, but not also supporting non-systemd systems is a (non-RC) bug and non-maintainer uploads to add that support are appropriate. systemd facilities may be used at the discretion of package maintainers, but 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. Choice hartmans2: systemd but we Support Exploring Alternatives The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debi
Time Line
>>>>> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Proposal: General Resolution on Init
Ian> Systems and systemd Facilities"):
>> Timeline:
Ian> Please can we have more time.
If you're worried about still finalizing wording or what happens if
we're actively in a productive discussion refiding the words of one of
the viable proposals, sure, I'd make sure we had more time.
But I think two weeks is enough time to judge basic support and
viability of a proposal. That is, I think within two weeks proposal
authors ought to be able to find seconds or find people who would second
if a particular likely-to-be-resolved issue is resolved.
You are right that this decision is not hugely timely.
However we've seen time and time again that the project views these long
discussions as costly.
I saw someone on IRC just yesterday saying they had recently spent 16
hours on init system GR stuff.
I was shocked.
I mean, yeah I've spent well over that time on this issue, but I've made
that my job.
If other develpers, particularly developers who are not primary
contributors to the discussion are already feeling burned out and are
spending significant time because they have to keep up, that is a real
significant cost to the project.
So, I want to be efficient about this process. I don't think it is
worth delaying for proposals that have not demonstrated that they will
be able to close issues and get necessary support to be on a ballot.
However, yes, if there is a subcommunity that is coming towards a
consensus to refine or merge a proposal, delaying to accomplish that
seems valuable.
If we're circling around not actually making progress, I'm less
supportive of a delay.
Re: [draft] Draft text on Init Systems GR
> "Ian" == Ian Jackson writes: Ian> The patterns I am trying to address with this are things like: Ian> * Vague RC bug reports against pieces of the non-systemd Ian> ecosystem, which do not actually describe a particular bug, or Ian> an approach acceptable to the submitter, and are therefore Ian> unresolvable. Ian> * Maintainers of key packages declining to relax strong Ian> dependencies on systemd components on the grounds of fairly Ian> marginal differences in functionality when a non-systemd Ian> alternative is chosen. Ian> * Declining to accept init scripts, or arguing against the Ian> inclusion of init scripts, on the grounds that they should be Ian> properly tested by the maintainer and the author doesn't Ian> consider testing them to be a good use of time. Ian> * In general, blocking the work of non-systemd contributors on Ian> the grounds that the arrangement that the non-systemd Ian> contributors are trying to create for non-systemd users is Ian> somehow suboptimal or broken, in the opinion of the Ian> systemd-supporting gatekeepers (be that maintainers, members of Ian> the release team, or anyone else). Ian> It is really unfortunate, but I have seen multiple examples of Ian> each of the first three specific patterns above. IMO we must Ian> address this. I strongly agree. I've also seen non-systemd contributors being inappropriate--disrespectful, abusing the BTS, and generally not being excellent to each other. I understand in the past you can probably find examples of systemd contributors doing that, and certainly I've seen the pattern of doomssaying about the longterm viability of non-system solutions. Today though, systemd contributors seem to block or produce vague and unactionable objections when they are being obstructive. Non-systemd contributors find themselves in a position of anger and probably fear and seem to be lashing out in frustration. I want to stress that I'm not judging anyone--not either side. I understand how we get to this point. But I strongly believe we must stop this behavior. We should figure out which work we're willing to do, do that work professionally, and politely decline the rest. It sounds like we share that goal, even if we see the approaches to get there differently. I think that the DPL, the TC, and anything the TC might evolve into will be critical forces in moving forward after the GR. For me as DPL, the big question is which direction to go to resolve the pattern. Ian> How about: Yeah this is much better. I do have a suggestion that I've included below. we close in on intent. My wording is not great, but we can refine wording after Ian> Maintainers of systemd components, or other gatekeepers Ian> (including other maintainers and the release team) sometimes Ian> have to evaluate technical contributions intended to support Ian> non-systemd users. Such contributions should be accepted, even Ian> if they are or may be of compromised quality, if the Ian> quality/risk is acceptable to the maintainers of non-default Ian> init systems and the surrounding community sh> and the risk will be born by the users of non-default sh> initsystems. To the extent that the risk will be born by users sh> of default initsystems, normal procedures for judging sh> acceptable risk should be used. Ian> Ian. Ian> -- Ian Jackson These opinions Ian> are my own. Ian> If I emailed you from an address @fyvzl.net or @evade.org.uk, Ian> that is a private address which bypasses my fierce spamfilter.
Re: Proposal: General Resolution on Init Systems and systemd Facilities
> "Ian" == Ian Jackson writes: Ian> For example, suppose upstream ship a timer unit. A Debian Ian> contributor wants to supply a patch to make the package use Ian> cron. You might very well want to use cron even with systemd; Ian> some people prefer cron's featureset. How is this supposed to Ian> be resolved in practice ? The non-systemd-using contributor of Ian> the cron job might which to simply add a dependency on cron and Ian> disable the timer unit by default. Or are the timer units Ian> supposed to be patched to be disabled when cron is installed ? Ian> It seems to me that these kind of technical details will need Ian> to be resolved via the policy process. These discussions are Ian> specific to each facility. We're agreed so far. Ian> In some cases we will want to Ian> simply provide an implementation of (perhaps a subset of) the Ian> systemd functionality. Ian> I think these decisions ought to be taken on a Ian> faciliy-by-facility basis. That's why my proposal sets out a Ian> set of criteria for judging whether a facility's interface Ian> ought to be adopted by Debian. Right. And the disagreement is whether the answer is a presumed yes you can use the facility or you need to go through the process ahead of time. I believe that my options accurately reflect the discussion I was trying to capture. The up-side of that is that it makes it easy to use new facilities. The down sides are the ones you've pointed out. As people find bugs they don't know how to solve, policy will have to catch up. But we're used to that. I think that you could find a few people who want to support both systemd timers and cron jobs together. And once you found a good way to do that, you could get it into policy. Your proposal blocks people from using the new facility until that discussion happens. Under Russ's option B and C, which I capture in my proposal, non-systemd users get degraded behavior until we agree on an approach and standardize it. In both cases we hopefully turn fights into bugs.
Re-Proposing: General Resolution on Init Systems and systemd
The secretary requested that I have each choice be self-contained. So I'm folding the header into each choice. The line of dashes separates each choice. I formally propose these general resolution options. Version 1385c4e4ba56da Choice hartmans1: Affirm Init Diversity Using its power under Constitution section 4.1 (5), 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. The GR process remains available if the project needs a decision and cannot come to a consensus. Being able to run Debian systems with init systems other than systemd continues to be something that the project values. With one exception, the Debian Project affirms the current policy on init scripts and starting daemons (policy 9.3.2, 9.11). Roughly, packages should include init scripts to start services that are included. Policy notes that early boot services like those started from /etc/rcS.d may be tied closely to the init system in use and thus may need to be handled differently for each init system. Init scripts are the lowest common denominator across all init systems. Packages may include support for init systems like systemd service units in addition to init scripts. Current policy makes it an RC bug to include a service unit without an init script. Policy editors are requested to amend policy; a package having a service unit but without an init script is no longer an RC bug, but including an init script is appropriate for a non-maintainer upload. Policy editors are requested to consider whether there are cases where removing an init script that used to be provided should be RC because it would break a system on upgrade. Once the community of users of an alternate init system have said that a solution is sufficiently functional for them, others should not generally second guess this determination. systemd unit files included in the package may use any systemd feature or service at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Init scripts must use only facilities common to all supported init systems in Debian and therefore may not use services that depend on systemd. Similarly, packages may freely use other systemd facilities such as timer units, subject to the above constraints, but not also supporting non-systemd systems is a (non-RC) bug and non-maintainer uploads to add that support are appropriate. systemd facilities may be used at the discretion of package maintainers, but 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. Choice hartmans2: systemd but we Support Exploring Alternatives Using its power under Constitution section 4.1 (5), 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. The GR process remains available if the project needs a decision and cannot come to a consensus. The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner. Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any
Re: Re-Proposing: General Resolution on Init Systems and systemd
>>>>> "Kurt" == Kurt Roeckx writes: Kurt> On Sat, Nov 16, 2019 at 11:35:27AM -0500, Sam Hartman wrote: >> >> The secretary requested that I have each choice be >> self-contained. So I'm folding the header into each choice. >> >> The line of dashes separates each choice. I formally propose >> these general resolution options. Kurt> Can you please clarify with which had you're doing this. I Kurt> think you intended to do this as DPL, but you used your Kurt> hartm...@debian.org email address. I'm doing this as DPL. I've spent a lot of time trying to facilitate an understanding in this space. It became clear based on policy editor comments and based on the patterns of behavior I've seen that we're not going to easily come to consensus on this issue, and that the project would be better off if we had a decision. So, as DPL, I've introduced a GR to try and facilitate that decision. Thus, I consider it reasonable to introduce the GR with the DPL hat on. You made several comments that you thought it sounded like the GR was overriding a delegate or was setting policy. No. If one of these options passes, the project is describing what it wants at this point in time. Just as a debian-devel discussion has no formal power, this GR will not have formal power. However, section 8.2 of the constitution says that delegates including the policy editors, and the release team are supposed to take into account consensus of the project and project discussions. Similarly, the DPL has responsibilities to listen to the project. I have high confidence that a decision in this space will give the policy editors the tools they need to break the consensus deadlock without having to resort to overriding them or setting policy as a project. That is, in this case, a non-binding statement that we know the project supports will be sufficient to unblock things. So I've proposed several such non-binding statements that the project could make. An informal statement is better anyway. If the policy editors run into some problem implementing this, they can come back to the project Likely we'll be able to get consensus on a way forward without resorting to another GR. If we set policy here, then we run the risk of denying our delegates flexibility to handle things they find moving forward. We probably could craft a resolution to avoid that risk. It is far easier to simply let the delegates know what the project wants in a non-binding way. If that ends up not being sufficient, we have several tools available to us later including revising delegations or future GRs. I also don't think it is appropriate to consider something overriding a delegate unless it is overiding a specific decision of a delegate. I think it is entirely reasonable to have delegations with overlapping responsibility or to propose delegating a specific decision to a group different than a group that might handle general issues in that space. That's not what I'm proposing here. signature.asc Description: PGP signature
Re: Re-Proposing: General Resolution on Init Systems and systemd
> "Kurt" == Kurt Roeckx writes: Kurt> But as you pointed out, I'm happy to interprete this as using Kurt> the 4.1.3 powers of the policy editors and release team, nor Kurt> do I really see a difference between 4.1.3 and 4.1.5. The big difference between 4.1.3 and 4.1.5 is that 4.1.5 is explicitly non-binding. I think the project should be able to make basically whatever statement it chooses to do so under 4.1.5 even if it also could have done so more forcefully in other ways.
Re: Re-Proposing: General Resolution on Init Systems and systemd
I am in fact going to accept Russ's amendment clarifying division of responsibility. I'm finding the amendment easy to accept, although I just need to update my working copy and repost. I'm finding replying to Scott's original message is taking a bit of wordsmithing.
Re: Proposal: General Resolution on Init Systems and systemd Facilities
>>>>> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Proposal: General Resolution on Init
Ian> Systems and systemd Facilities"):
>> Timeline: I think that two weeks for discussion of this GR seems
>> about right based on what's happened in the last week. The
>> constitution allows the DPL to change the discussion period by up
>> to a week. The discussion period is normally reset by the
>> proposer accepting any amendment or making a modification to the
>> proposal. If an amendment is accepted, I am likely to use that
>> power such that the discussion period is the longer of two weeks
>> from when the secretary sends mail to debian-devel-announce, or
>> seven days past the time of the last amendment being accepted.
>> In other words, if I accept an amendment in the next week, I'm
>> likely to keep the total discussion period at two weeks.
To clarify, my understanding is that the discussion period started
November 16.
So, we're talking about a minimum discussion period expiring on
November 30.
I assumed the secretary would interpret the constitution differently and
that only the proposer of the original resolution could accept
amendments.
I seem to recall Manoj interpreted things that way back in the day.
So, at the time I wrote that text, I was under the mistaken belief that
I was the only one who could accept amendments. (I'm glad the secretary
has interpreted things differently.)
My assumption is still that only me accepting amendments resets the
minimum discussion period.
If that's not how the secretary sees things then I don't understand this
process at all and will need to have a re-read of the constitution and a
re-think about things.
I'm not making a value judgment about what the constitution should say,
just a judgment about past practice and my reading of the constitution.
Another way to understand what I intended is that I will do what I can
to keep the minimum discussion period ending at November 30.
That said, I'm very open to the idea of delaying calling for a vote if
people are finalizing wording that has received sufficient seconds or
for whichthe following two conditions are true:
1) People have indicated a desire to second if certain issues are
resolved;
2) It looks like there is a reasonable chance of resolving those issues
So, to be concrete. Right now, your proposal has received enough
support that I think it's worth trying to resolve outstanding amendments
before calling for a vote. (Although I also think we can probably do
that before November 30). Right now, I don't think Dmitry's proposal
has received enough support that I would want to delay to resolve
amendments. That could easily change in a week and a couple of days.
--Sam
Re: Proposal: General Resolution on Init Systems and systemd Facilities
>>>>> "Russ" == Russ Allbery writes: Russ> Sam Hartman writes: >> To clarify, my understanding is that the discussion period >> started November 16. So, we're talking about a minimum >> discussion period expiring on November 30. Russ> Your acceptance of my amendment reset the clock, at least by Russ> my reading of the constitution. That happened on the 19th of Russ> November, so the two week discussion period will now expire on Russ> the 3rd of December. Russ> (This is actually a little bit murky since I didn't call for Russ> seconds and you accepted the amendment directly. Russ> Procedurally, it looks like I probably should have called for Russ> seconds to be in less ambiguous territory, so we may need a Russ> secretarial ruling here.) I did? I thought I told you I would accept the amendment. It's my intent today or tomorrow to accept the amendment and to update the discussion period to continue to expire on November 30.
Amendment Accepted:Re: Resolution on Init Systems and systemd
Kurt, I'd like to accept Russ's amendment to choice hartmans1. Attached please find a complete replacement for all three choices, although only hartmans1 has changed. Also, please find a diff in case that's easier for you. Using powers under constitution 5.1 (8), I vary the minimum discussion period so that the minimum discussion period ends on November 30. My inten here is to accept the amendment without resetting the minimum discussion period. Version 2e62d001f Choice hartmans1: Affirm Init Diversity Using its power under Constitution section 4.1 (5), 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. The GR process remains available if the project needs a decision and cannot come to a consensus. Being able to run Debian systems with init systems other than systemd continues to be something that the project values. With one exception, the Debian Project affirms the current policy on init scripts and starting daemons (policy 9.3.2, 9.11). Roughly, packages should include init scripts to start services that are included. Policy notes that early boot services like those started from /etc/rcS.d may be tied closely to the init system in use and thus may need to be handled differently for each init system. Init scripts are the lowest common denominator across all init systems. Packages may include support for init systems like systemd service units in addition to init scripts. Current policy says that packages must not include a service unit without an init script. Policy editors are requested to amend policy; a package including a service unit should include an init script (meaning that not doing so is considered a bug), but this is not required (meaning that it is not a serious bug). However, adding an init script to such a package is appropriate for a non-maintainer upload. Policy editors are requested to consider whether there are cases where packages must not remove an init script that used to be provided because it would break a system on upgrade. The release team is requested to consider whether there are cases where removing an init script should be a release-critical bug for the same reason. Once the community of users of an alternate init system have said that a solution is sufficiently functional for them, others should not generally second guess this determination. systemd unit files included in the package may use any systemd feature or service at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Init scripts must use only facilities common to all supported init systems in Debian and therefore may not use services that depend on systemd. Similarly, packages may freely use other systemd facilities such as timer units, subject to the above constraints, but not also supporting non-systemd systems is a (non-serious) bug and non-maintainer uploads to add that support are appropriate. systemd facilities may be used at the discretion of package maintainers, but 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. Choice hartmans2: systemd but we Support Exploring Alternatives Using its power under Constitution section 4.1 (5), 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. The GR process remains available if the project needs a decision and cannot come to a consensus. The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing pa
Re: Proposal: General Resolution on Init Systems and systemd Facilities
>>>>> "Russ" == Russ Allbery writes: >> Sam Hartman writes: >>> It's my intent today or tomorrow to accept the amendment and to >>> update the discussion period to continue to expire on November >>> 30. Russ> Sam said that he'd be willing to delay if needed if an Russ> additional proposal received enough seconds to be on the Russ> ballot. Russ> I think it's important that we hold this vote sufficiently Russ> clear of the winter holidays that we don't run into trouble Russ> with low participation. To me, that implies that the absolute Russ> latest we should start this vote is on December 8th. Russ> How about this compromise: Russ> * Sam sets the conclusion of the discussion period to November Russ> 30th for the current ballot, which would probably result in a Russ> vote starting on December 1st (giving the Secretary some time Russ> to set up the vote). I think the current ballot options are Russ> fairly stable. Russ> * If any new proposal receives enough seconds to gain a slot Russ> on the ballot by November 27th, Sam agrees that he will reset Russ> the discussion period to end on somewhere between December 4th Russ> and 7th. (I personally would just lock down the 7th for that Russ> contingency, but leaving this open in case there's some reason Russ> I'm missing to end a bit earlier.) That will provide at least Russ> an additional week to hammer out any remaining wording Russ> problems with that option. In general, I think you've approximately restated what I already said. I'm not going to commit to a specific "compromise," because I think there are some corner cases. As an example, if Dmitry's proposal got five seconds tomorrow, I think we might still be in shape for a November 30 end of discussion. I'd make that call sometime next week. But in general, what you're talking about is very well aligned with my thinking. If on the other hand, Dmitry's proposal got enough seconds (or people saying they planned to second the next version once it came out) next week, delaying sometime between the 4th and 7th would seem to be more of a requirement. --Sam
Should I withdraw choice hartmans1?
Hi. By this point we have a group of people who have consistently seconded options that promote init diversity. That is, we have a group of people who have gotten behind specific options. I'd like to ask especially those people whether choice hartmans1 should be removed from the ballot. Within limits, I think more options is better, so my general preference would be to keep the option. However especially if that option is sene as a distraction by the init diversity proponents, that could be a significant concern. At one point Dmitry expressed a preference for removing that option, but I don't think I've gotten feedback from others who have seconded (or proposed) the diversity options now on the ballot. --Sam
Procedural rangling
> "Kurt" == Kurt Roeckx writes: Kurt> I always struggle with trying to understand that part, but my Kurt> current interpretation is different. The page shows the Kurt> discussion perriod starting at the 19th, which is when Ian's Kurt> proposal got enough sponsors. My understanding is that you believe any formal amendment achieving sufficient sponsors restarts the discussion period. You may also believe that a sponsor of a formal amendment accepting a change to that amendment resets the discussion period. I argue below that is inconsistent with the constitution and introduces significant strategic problems. I claim that's bad on three grounds: 1) I assert that it is inconsistent with past practice. I'll be happy to go on a dive and look at this issue in the past, but I'm fairly sure we're diverging here from what we have done. 2) It is open to serious irreconcilable strategic abuse. In particular, it means that any six developers can indefinitely block us from voting by continuously introducing amendments and getting them onto the ballot. If it resets the discussion period each time that happens, then I see no counter to that strategy. (We can bring it up to 10 developers needed if you consider the counter strategy of DAM expelling developers after they pull this a few times.) 3) I think it is textually inconsistent with the constitution. To make this argument I'm going to make the argument that only the proposer of a resolution can accept amendments. That is, the person making a formal amendment is not a proposer of a resolution in the sense of appendix A.1 (2). I believe this is supported by the text. Proposer defined (4.2 (1): 1. The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee. That is, 4.2(1) acknowledges that both resolutions and amendments can be proposed, but treats them separately. A.1. Discussion and Amendment Section A.1(1) discusses discussion: 1. Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution. Again, resolution and amendments are treated separately. 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. In this text an amendment may be accepted by the resolution's proposer. No provision is made for an amendment to be accepted by an amendment's proposer. 5. The proposer of a resolution may suggest changes to the wordings of amendments; these take effect if the proposer of the amendment agrees and none of the sponsors object. In this case the changed amendments will be voted on instead of the originals. This continues the trend of treating amendments separately from the resolution. That is, if amendments and resolutions were treated symmetrically, then the text would talk about how proposers of amendments and the resolution could suggest changes to amendments and the resolution. Instead, this text goes out of its way to treat the categories separately. 6. The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted. Section A.2 (4) describes resetting the discussion period: 4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted. As a reminder, Section A.1(2) quoted above defines what it means for a formal amendment to be accepted. That's something that happens when the proposer of a resolution accepts an amendment and integrates it; it is not something that happens when a formal amendment receives enough sponsors to be on the ballot. In conclusion, I think the text of the constitution is very clear that a proposal achieving k sponsors does not reset the discussion period. Interpreting things otherwise opens up a significant opportunity for strategic abuse. I believe that it also is inconsistent with past practice, although I have not substantiated that claim. Unfortunately, under this interpretation, it is a lot less clear that proposers of formal amendments can easily accept small changes to their amendments without the cooperation of the proposer of the general resolution. Here's recommended interpretation to allow us to continue to do that while be consistent with th
Re: Should I withdraw choice hartmans1?
> "Ian" == Ian Jackson writes: Ian> I think the title "Affirm Init Diversity" for hartmans1 is Ian> rather misleading. hartmans1 seems to legitimise uncontrolled Ian> adoption of non-daemon-startup systemd features; in this sense Ian> it is weaker even than my compromise proposal. Would you like to propose a title you believe is more accurate?
Re: Should I withdraw choice hartmans1?
>>>>> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: Should I withdraw choice hartmans1?"):
>> Would you like to propose a title you believe is more accurate?
Ian> It is difficult for me to do that without being tendentious and
Ian> possibly offensive, since I don't like the proposal. What
Ian> comes to my mind is something like Ineffectually hope to
Ian> promote init diversity but I don't think you will like that!
So, in such situations, it often helps to focus on what a proposal does
rather than your opinion of it.
How about:
Init Diversity is Important but not Serious
I think two key differences between this choice and Dmitry's option are
that:
A) Init diversity issues are valid for an NMU but are never serious
B) Dmitry's option puts specific obligations on maintainers to write
init scripts when it is easy to do so.
so, perhaps we can find a title based on those.
I'll also note that while you did take the opportunity to talk about why
you'd rank the proposal below FD, you did not answer the question of
whether you would like to see it removed from the ballot.
Re: Should I withdraw choice hartmans1?
> "Ian" == Ian Jackson writes: Ian> I think the most important difference between your proposal and Ian> Dmitry's is that your proposal, as I say, (and I think unlike Ian> Dmitry's): Ian> legitimise[s] uncontrolled adoption of non-daemon-startup Ian> systemd features Choice hartmans1 permits the use of non-startup systemd features. Under this choice, that's fine so long as the package continues to work with non-systemd systems. I think that's true with Dmitry's choice as well. Under his choice, I think a package can do whatever it likes so long as it works when systemd is not pid 1. Under choice hartmans1 failing to work when systemd is not pid 1 is a bug. It's a sufficiently important bug that patches can be NMUed to fix it. But it is not a serious bug. Under Dmitry's proposal that is also a bug, but I assume that the word "must" even outside of a policy context means Dmitry is hoping that bug will be considered RC. Under both proposals, a package that fails to work witha non-systemd pid1 is buggy. In my mind, there is a significant gap between making something buggy and legitimizing something, and I think choice hartmans1 is closer to making something buggy than legitimizing it. If you see the difference in bug sevirity as legitimizing, well, we find ourselves not in agreement. If, on the other hand, you find that the text of the proposal, beyond its effects, tends to legitimize the practice, that is not my intent.
Re: Proposal: Init Diversity
> "Kurt" == Kurt Roeckx writes:
Kurt> On Thu, Nov 21, 2019 at 02:39:09PM +, Ian Jackson wrote:
>> Kurt Roeckx writes ("Re: Proposal: Init Diversity"): > I've
>> currently put the title to "Packages should support >
>> non-systemd". Suggestions welcome.
>>
>> Dmitry titled his posting "Init Diversity" which I think is
>> appropriate.
Kurt> We already have an "Afferm Init Diversity" ...
I'm working on a new title for hartmans1; I'm hoping Ian or someone else
will work with me to do that.
My preference would be
Dmitry's option would be
"Init Diversity is Required"
and
hartmans1 would be "init Deversity is Important and NMUable but not
Serious"
In my mind that's the big difference between Dmitry's option and
hartmans1, but I'm still working to understand Ian's point of view.
(Well, that an hartmans1 is longer, but I'm not sure it says much more
than Dmitry's option with a should instead of a must).
Choice Hartmans1a
Tl;DR: I think this option is strictly better than the current hartmans1. If you disagree please let me know. Especially if you want to see the current hartmans1 on the ballot let me know. I'd like to replace hartmans1 with this option. I've attempted to revise choice hartmans1 along the lines of Dmitry's proposal. This is consistent with the spirit of what I proposed earlier, but I hope addresses Ian's objections and makes it clear that the difference is the severity of the bug. Based on Simon's comments I think it is relatively important to have this option on the ballot. If it is not on the ballot we force people who find the RC issue important to make a choice; some of them get pushed towards Dmitry's options and some of them get pushed towards other options. I suspect we could argue over which positions that most benefits, but it seems to me like such strategic culling of options is not in the project's interest. I'm still open to arguments that the option should be removed from the ballot, but I'm much more inclined to keep it than I was this morning. Choice hartmans1A: Init deversity is Important and NMUable 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. The GR process remains available if the project needs a decision and cannot come to a consensus. 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. Software is not to be considered to be designed by upstream to work exclusively with systemd merely because upstream does not provide, and/or will not accept, an init script. 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. signature.asc Description: PGP signature
Re: NOTA option
> "David" == David Prévot writes: David> Hi, Will there be a NOTA (none of the above) option on the David> ballot, or should one propose it formally? Not being David> satisfied by any of the proposed option may not mean one David> wants FD (further discussion) about it. There will be FD. If you want a NOTA option, it needs to be proposed. However, I'd argue that you should be clear about what you mean. For example in 2014, there was a "we don't need a resolution about this" option. But NOTA in and of itself is not very well specified. What are you hoping happens if you vote for that.
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
>>>>> "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
> "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
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,
Replacing Proposal A
Dear Secretary: Based on discussion, I'd like to replace Proposal A with the following amended text; I accept this amendment. I continue to adjust the discussion period to end November 30. Based on Holger's recommendation I adjusted the title of the choice. If you prefer the title you have now, I also accept that. Choice hartmans1: Init deversity is Important 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. The GR process remains available if the project needs a decision and cannot come to a consensus. 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. 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, and/or will not accept, an init script. 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. For my reference version a9a4121beb Choice hartmans1: Init deversity is Important 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. The GR process remains available if the project needs a decision and cannot come to a consensus. 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. 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, and/or will not accept, an init script. 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. signature.asc Description: PGP signature
Re: Replacing Proposal A
>>>>> "Sam" == Sam Hartman writes: Sam> Dear Secretary: Sam> Based on discussion, I'd like to replace Proposal A with the Sam> following amended text; I accept this amendment. Sigh, and introduced a typo in the title: Sam> Choice hartmans1: Init deversity is Important How about Init Diversity is Important Kurt, I think that titles are ultimately under your control. I give any necessary permissions I might need to give for you to fix the title. signature.asc Description: PGP signature
Re: Replacing Proposal A
>>>>> "Sam" == Sam Hartman writes: Sam> Dear Secretary: There's another typo in my replacement text for proposal A. Sam> support for running without systemd is available. It is a Sam> important bug (although not a serious one) when packages should That should be *an important bug* I.E. I got the article wrong. I propose correcting this change under A.1 (6) assuming no objections in 24-hours (per the requirements of that section). signature.asc Description: PGP signature
Re: Replacing Proposal A
> "Kurt" == Kurt Roeckx writes: Kurt> It's my current interpretation that the title you gave was Kurt> part of the text, and so not under my control. Which is why 4 Kurt> of the 5 options have 2 titles, one that's under my control, Kurt> followed by the text that's not, that also has a title. What I tried to do was give an initial suggestion of a title to help you out. I'd prefer that at least for my options you assume you have control of the title. I give permission for that if you choose that option. Alternatively, if you'd rather interpret this as me proposing and accepting fixing the typo under A.1 (6), I'm fine with that two. signature.asc Description: PGP signature
Re: Proposed amendment to Proposal D
> "Kurt" == Kurt Roeckx writes: Kurt> On Mon, Nov 25, 2019 at 02:39:05PM +0100, Simon Richter wrote: >> Hi, >> >> On Mon, Nov 25, 2019 at 01:09:10PM +, Ian Jackson wrote: >> >> [change removing regret about having another GR] >> >> > Unless anyone objects by 1400 UTC on Wednesday, I intend to >> accept > this amendment, assuming that this is procedurally >> kosher. >> >> I'm also in favour of that. My understanding of procedure is that >> seconds remain valid, and if anyone of the original seconders >> objects, they need to explicitly rescind and/or propose the >> original text as a new option, which then requires the usual >> number of seconds. Kurt> I think under a strict reading of the constitution, only Sam, Kurt> as the proposer of a resolution, can suggest changes and then Kurt> Ian can agree to them. As long as nobody complains, I will Kurt> just allow Ian to accept it. If it helps I hereby suggest Steve's change. In general I'm very in favor of the secretary interpreting the constitution to allow Ian or other proposal authors to update their proposals in response to feedback. My preferred such interpretation would be that Ian is withdrawing and submitting his proposal, and the secretary interprets the sponsorships to still apply unless that is clearly inconsistent with the text of the sponsorship. If the secretary would rather assume that I as proposer of the resolution suggest any necessary changes to the formal amendments I'm fine with that too. Basically I don't want to get in the way of people refining text. signature.asc Description: PGP signature
CFV Timing and length of voting period
Question at the end about length of voting period. Hi. Things seem to be calming down here. Assuming no changes, I think having discussion end on November 30 is fine. The sorts of changes that might complicate that include: a significant new issue coming up, or a new proposal coming up that seems like it might plausibly attract enough sponsors. The recent change Ian is making doesn't sound like a complex new issue: people proposed an improvement and it looks like Ian will quickly be able to agree and change his proposal. Assuming discussion ends on November 30, I think it would be good to start the vote as soon as the secretary can. Rationale is to give people as much pre-holiday voting timing as Russ suggested. I'm discussing Kurt's constraints with him. The earliest time might be midnight UTC on december 1. My preference would be a couple of days later, but I'd prefer December 1 to December 7 or 8. One question. Should I extend the voting period to give people more time to vote given that holidays are near. I'm not sure it would help much because I think the primary effect of doing that would be to extend the voting period into the middle of the holidays. But if people think it might help and would not be harmful I'm happy to do so. --Sam signature.asc Description: PGP signature
Re: Please drop/replace the use of the term "diversity"
> "Enrico" == Enrico Zini writes: Enrico> On Wed, Nov 27, 2019 at 11:27:13AM +, Chris Lamb wrote: >> May I gently request we replace the use of the word "diversity" >> throughout the "init systems and systemd" General Resolution >> prior to it being subject to a plebiscite? Enrico> Thanks for raising this issue, and yes, please! Enrico> Something like s/init diversity/support for multiple init Enrico> systems/ seems to me to address the issue you raise, Enrico> introduce more clarity, and it sounds to me also somewhat Enrico> more precise. For example: I hear what you are saying. But the people who favor choice in init systems really do seem to identify with the term "init diversity." I think it is important to let people choose their own labels, and choose how they would be known. In my mind letting people self identify is more important than the quasi-political aspects of the term diversity. I supported Holger's push to remove diversity from the title of proposal C because the systemd community does not seem to value or identify with the diversity label. But diversity is in the name of the mailing list where support for non-systemd init systems is discussed. It's been a term that community has been using for years. Now is not the time to change that unless that community supports the change. --Sam
Re: Please drop/replace the use of the term "diversity"
I'm definitely fine with Kurt's revision to the title of Proposal A given the similar change to proposal E and Ian's comments. If I'm permitted to make the following change under A.1(6) (that is, permitted to make the following change without resetting the clock) I propose to make the following small change in proposals A, B and C: old: The project issues the following statement describing our current position on Init systems, Init system diversity, and the use of systemd facilities. new: The project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. I considered combining init systems and multiple init systems. I have higher confidence that I'm not changing the meaning of the sentence without combining the clauses though so I propose the smallest possible change. signature.asc Description: PGP signature
Re: Please drop/replace the use of the term "diversity"
> "Kurt" == Kurt Roeckx writes: Kurt> So I did an s/Init system diversity/multiple init Kurt> systems/. The text in B and C doesn't match exactly, since B Kurt> and C still have "Using its power under Constitution section Kurt> 4.1 (5), ". It is intentional that the text in B and C includes the 4.1(5) language and A does not. I don't think it matters, but since proposal E didn't specify which subsection of 4.1 it was using, I didn't want to specify that in A.
Re: Review of proposals
> "Marco" == Marco d'Itri writes: Marco> lu...@debian.org wrote: >> In order to save voters' time by making it possible to read >> proposals in a more sensible order, I think they should be >> re-ordered as: Marco> I agree. I don't object to an ordering change. I do note that people have already written blog posts and commentary with the current ordering and changing the ordering might confuse some people. However, I agree that Lucas's ordering would be better in a lot of ways. I'm fine with whatever the community/secretary decide on this issue.
Re: Typo in proposal B
> "Ian" == Ian Jackson writes:
Ian> Martin Michlmayr writes ("Typo in proposal B"):
>> "It is important that the project support the efforts"
>>
>> s/support/supports/?
>>
>> (I know British and American English don't agree whether an
>> organization is singular or plural but it seems to me that "the
>> project" is singular.)
Ian> I think this is a subjunctive.
I agree with Ian.
I tend to try and write in Chicago Style except where I disagree with
that style (for example their approach to gender is more conservative
than meets the needs of audiences I write for).
I considered spending a while with the grammar section of CMOS 17 last
night to decide support and supports both sound correct to me. My
first guess is the same as Ian's: I think that is subjunctive rather
than indicative mood.
However, I realized that at the point where I'm considering spending 30
minutes with a style guide, we've already won. We've already reached
the quality necessary for a GR.
Re: Please wait a bit longer before calling for a vote
> "Ansgar" == Ansgar writes: Ansgar> Hi, I would like to ask people to wait a bit longer before Ansgar> calling for a vote. Michael Biebl said he is looking into Ansgar> drafting an alternative, but has been too busy with work in Ansgar> the last few days. He would therefore like to have a bit Ansgar> more time to prepare. I'm sorry, but I've been trying to work with Michael for a number of months to get his input on these issues. He has told me that the problem is not me, but that even answering the question of why responding to the mails I have sent is too emotionally difficult to engage in. He's been aware that I'm considering this issue since September and has known that I planned to propose a GR since my September/October bits mail. Michael has been invited to engage in this process repeatedly, but has chosen not to do so. There's nothing wrong with that. We are all volunteers. However, when you choose to not engage with a discussion, you need to gracefully accept that you lose influence. Doing anything else means that you're trying to block the work of others in a very disrespectful manner. But there is a huge problem with trying to block forward motion at the last minute with a completely new option that no one has seen. In this instance, blocking on Michael would be implementing exactly one of the negative patterns Ian talks about in his proposal. As we've discussed before, there are two significant costs to waiting: * Many people have talked about the high costs of these discussions. I've seen comments to that effect on debian-devel and from multiple people on IRC. There have been a lot of emails in this discussion. Following this has been a significant cost for all of us. Dragging that out has costs. * Delaying the CFV runs into significant chance of having most of the vote be up against the holidays, making it harder for people to vote. Delaying the CFV into January leaves the discussion open way too long at least if you value the concerns raised about the cost of the discussion. Depending on how the discussion between Lucas and Ian goes, I can see delaying the CFV for a couple of days while they hammer out amendments. People who want to wait are free to rank further discussion above other options. You can still express your preferences among the existing options while ranking further discussion first. I do not support delaying the CFV for an option that has not gained sponsors. signature.asc Description: PGP signature
Re: Please wait a bit longer before calling for a vote
> "Simon" == Simon Richter writes: Simon> While I generally agree with Sam here that it is rather Simon> disingenious to add a new option right at the end of the Simon> discussion period, I think that having something proposed by Simon> the systemd maintainers on the ballot will be worthwhile Simon> because they have one of the best vantage points to see Simon> future points of contention and whether the GR is likely to Simon> guide us through them. Martin Pit has publically stated he's one of the people I reached out to in developing my proposals. As I understand, he's been active in maintaining systemd both in Ubuntu and Debain.
Re: Review of proposals
> "Simon" == Simon Richter writes: Simon> Hi, Simon> On Fri, Nov 29, 2019 at 11:44:55AM +, Ian Jackson wrote: [regarding declarative facilities] >> I have heard more than one person say that they are unhappy that >> the current situation has been blocking specifically this kind of >> progress. Simon> In my opinion, that question is the core of the argument Simon> we're having. Daemon startup is effectively solved on the Simon> technical side, and the only question remaining there is Simon> whether including an init script should remain mandatory or Simon> not. Simon> Non-init-related facilities are where I'd expect Simon> incompatibilities to arise, and it is a bit sad that there is Simon> only one amendment that effectively addresses this question Simon> -- because if amendment D doesn't win, this GR provides Simon> absolutely no guidance on what to do about packages that do Simon> not work properly or at all if systemd is not PID 1. I actually think all of the options provide guidance on this. First of all, under all options currently on the table, programs like cockpit that are designed for systemd and that have no way of working without systemd are permitted. That is, under all five current options, my reading is such programs are permitted and non-buggy. If a program is not explicitly designed for systemd by its upstream, under proposal E, it is RC buggy. Under proposal A, it is buggy, NMUs are encouraged, but it is not inherently RC buggy. Under proposal C, the project has said that supporting multiple init systems is not a priority, so fixing bugs that happen when systemd is not pid 1 is not a priority. I think you could still file a wishlist bug for that situation. Proposal B is also clear: >Packages may use any systemd facility at the >package maintainer's discretion, provided that this is consistent with >other Policy requirements and the normal expectation that packages >shouldn't depend on experimental or unsupported (in Debian) features >of other packages. Packages may include support for alternate init >systems besides systemd and may include alternatives for any >systemd-specific interfaces they use. Maintainers use their normal >procedures for deciding which patches to include. That is, the maintainer gets to decide what facilities they use and how important it is for their package to work when systemd is not pid 1. Proposal B involves a commitment to integrating technologies like elogind into the project, but *not* a commitment to integrating these technologies into leaf packages. That is, proposal B is about affirming Debian as a place where we can experiment with technologies that enable alternate init systems, while leaving which alternate init systems work for a given package up to those maintainers. Proposal B is not the option you want if you value sysvinit or runit as a general purpose init system in Debian. --Sam
Re: Review of proposals
> "Russ" == Russ Allbery writes: Russ> Sam, I think you misunderstood Simon's concern. He's not Russ> looking for guidance for packages that don't work properly Russ> with sysvinit. He's looking for guidance for packages that Russ> don't work properly with *systemd* (the inverse of that Russ> problem). You're correct. I totally misunderstood the question. Thanks for pointing this out and sorry for getting it wrong. For me, whether a package runs when systemd is not pid 1 is not a core question. I suspect that natural forces will cause reasonable things to happen. For example many maintainers want their packages to work in the default configuration.
Question Under Proposal D: Compile Time Option
Ian, I find that I'm not able to answer Simon's question with regard to Proposal D. Imagine that we have a program that has compile time support for systemd and for other mechanisms. It provides enhanced functionality when built against systemd, but when so built, it cannot run without systemd. It's packaged that way in Debian. Someone files a bug with a patch that changes the compilation option to support the non-systemd bug, removing the enhanced systemd functionality. What does proposal D say about this? Is the package RC buggy under proposal D until this patch is applied? Does the maintainer have the option to retain the enhanced functionality?
Re: Proposal: Focus on systemd
Hi. I'm trying to figure out if the new proposal is redundant with proposal C. The text is obviously very different, but I'm trying to figure out if there are any practical differences. Understand this is not a criticism of this proposal, but if there are no significant practical differences I am enclined to withdraw Proposal C. Differences I notice: * The preamble is shorter. I think it has the same effect though. If the intente of Proposal F is to limit our ability to change things if we reach a consensus more than proposal C, I'd like to see this more explicitly spelled out. However, my current assumption is that as a statement under 4.1(5) it would be reasonable for project consensus should it diverge from this GR to guide the project without repealing the GR. * The text about working with downstreams is different. Unless explicitly directed otherwise by the project I at least plan to continue to work with downstreams and help them figure out where their efforts can be contributed and where they cannot. So, I don't see this as a change. * The language about using systemd facilities is even stronger than that in proposal C. Are there any other changes that actually effect what maintainers could or could not do between proposal C and F?
Re: Proposal: Focus on systemd
>>>>> "gregor" == gregor herrmann writes: gregor> On Fri, 29 Nov 2019 18:12:48 -0500, Sam Hartman wrote: >> I'm trying to figure out if the new proposal is redundant with >> proposal C. The text is obviously very different, but I'm trying >> to figure out if there are any practical differences. Understand >> this is not a criticism of this proposal, but if there are no >> significant practical differences I am enclined to withdraw >> Proposal C. gregor> Without having thought this through, I have a gut feeling gregor> that you could withdraw all of your original proposals, gregor> because we now have 3 clear proposals, worded by the gregor> respective proponents, for the 3 general directions: gregor> Dmitry's pro multiple init systems variant, Ian's compromise gregor> proposal, and now tbm's clear pro systemd text. Proposal B is not a compromise proposal in the same direction as Ian's. Proposal B is a lot closer to proposal C/F than anything Ian would support. Proposal B is targeted at a different kind of compromise. One that I heard under the subtext of people I was talking to who were not involved enough that they were going to write their own text. People who are skeptical of systemd, but who believe it is superior to the other existing init systems. The big difference between proposal B and F/C is that proposal B obligates gatekeepers like the release team to think about the issues involved in integrating technologies that might provide alternatives to systemd. It says that as a project we'll work with people to run experiments at a global level, but does not commit individual maintainers to support these experiments. Under proposals C/F, the project level gatekeepers probably wouldn't cooperate with such experiments. Under all three systemd options (B/C/F), individual packages are not obligated to support alternate init systems.
Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
> "Bdale" == Bdale Garbee writes: Bdale> Guillem Jover writes: >> I think the current GR is incorrectly framing the problem at >> hand, as if it was just an init system selection. Bdale> This resonates with me, but... >> I'm thus proposing the following: Bdale> I find this really appealing as a higher-level statement of Bdale> values and intent, but unfortunately, I don't think the text Bdale> does anything to help resolve the problems that Sam set out Bdale> to try and tackle with this GR. Bdale> I therefore find myself unwilling to second it, even though Bdale> on some level I would really like to. I concur with Bdale and Russ. If this option wins I find that I wouldn't know how to go forward. I started this process because there were issues coming before me as DPL that I didn't know how to address because I didn't understand the direction of the project. This issue gives no guidance on the sorts of issues that I and the policy editors are facing. This option provides no guidance on how to approach the patterns of behavior that Ian and I have seen on our lists. --Sam
Withdrawing Proposal C; Option Ordering; CFV Timing
First, if it does not reset the minimum discussion period, I'd like to withdraw proposal C. I think the overlap between Proposal C and F is significant and we have not identified differences that appear to be important to our community. I don't plan to make aCFV before Tuesday. Whether even that makes sense depends on what happens between now and then. I continue to believe it is very important to start voting by December 8. based on feedback received so far, I do plan to ask to extend the voting period to three weeks. Obviously others could choose to make a CFV sooner. At this point, speaking as an interested party, but not the DPL, I'd request that we not reorder the options. I've found that I need to talk in mails, IRC, notes to myself about the specific proposals by letter. I have seen others do the same. I think that the cost of confusion is high enough at this point that I'd rather not see us reorder. If you do reorder, please please don't change the web links like https://www.debian.org/vote/2019/vote_002#textf (the link to Proposal F's text). I do agree that reordering would have been nice. signature.asc Description: PGP signature
Re: Withdrawing Proposal C; Option Ordering; CFV Timing
> "Kurt" == Kurt Roeckx writes: Kurt> Anyway, I'm not sure what the "I'd like" means. Is that just Kurt> an intention to do it, or did you do it? I withdraw Proposal C. signature.asc Description: PGP signature
Re: Withdrawing Proposal C; Option Ordering; CFV Timing
>>>>> "Kurt" == Kurt Roeckx writes: Kurt> On Sat, Nov 30, 2019 at 05:15:25PM -0500, Sam Hartman wrote: >> >>>>> "Kurt" == Kurt Roeckx writes: >> Kurt> Anyway, I'm not sure what the "I'd like" means. Is that just Kurt> an intention to do it, or did you do it? >> >> I withdraw Proposal C. Kurt> I have removed the proposal from the page. I'm not sure that Kurt> is the best thing to do. Are you saying you wish I had not withdrawn it, or are you saying that you're not sure how best to mark it?
Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
> "Russ" == Russ Allbery writes: Russ> Could you provide some more information about what your Russ> concern is here? libsystemd-dev depends only on libsystemd0, Russ> which has a pretty tiny list of dependencies and shouldn't Russ> require that systemd be running so far as I know. Are you Russ> thinking of test suites that assume systemd is available? pkg-config for systemd is in systemd not libsystemd-dev
Re: GR timing and "accepted" amendments
> "Ian" == Ian Jackson writes: Ian> It seems to me that if improvements to G (say) become available Ian> and are acceptable to the proposer, they should be on the Ian> ballot, probably instead of the existing G. Because of Ian> ambiguity in the constitution (sorry) it is not clear who can Ian> formally accept such an amendment, and also there is the Ian> problem that it might reset the discussion period. I think Kurt and I have both been under the interpretation that proposers of formal amendments have been withdrawing and replacing their proposals, and that sponsorship continues to apply unless it's clear that it does not. I think we're all agreed that proposers of formal amendments should be able to update things. I was considering something similar to what you propose though to remove the possibility of challenges if a sponsor should withdraw at the last minute, or something. I was effectively considering (especially if there were late changes) becoming an additional sponsor as DPL for anything that was discussed and seemed to address the questions that got us here. So, no, I would not feel comfortable sponsoring G in its current form for the reasons you, Russ, Bdale, Sean and I have stated. But yeah, if the DPL becoming an additional sponsor of an amended G would remove ambiguity as we approach CFV time, I can see doing that. --Sam
My attempt at a Voting Guide
FYI, see https://hartmans.livejournal.com/99642.html for my attempt at a voting guide on the proposals currently on the ballot.
Re: Withdrawing Proposal C; Option Ordering; CFV Timing
> "Bdale" == Bdale Garbee writes: Bdale> Kurt Roeckx writes: >> I'm thinking about renaming F to just "Focus on systemd", to make >> it shorter. I'm not sure how devotee is going to like wrapping >> long lines. Bdale> Not sure I "get a vote" on this, but that would work fine for Bdale> me. The text should adequately elucidate the objectives, so Bdale> trying to summarize them in the title doesn't add much. I think the longf title was much more important with Proposal C on the ballot.
Re: My analysis of the proposals
> "Uoti" == Uoti Urpala writes: Uoti> IMO encouragement for supporting alternative systems could be Uoti> reasonable, but only for actual new innovation; maintainers Uoti> should be explicitly permitted to remove any existing sysvinit Uoti> scripts and refuse addition of similar scripts. Systemd units Uoti> should be no worse a basis to bootstrap a new system. This is what I tried to capture with Proposal B. I wrote a blog post yesterday which still should be on planet discussing my thoughts about this and discussing some of the risks of that proposal. That said, parts of your message would have been more constructive if they were phrased more politely. It's possible to disagree with people (even very strongly) while still respecting that there are different opinions. As a recipient of such disagreement I've found Debian to be a much more enjoyable place to be when people take the time to do that. --Sam
Re: Question Under Proposal D: Compile Time Option
> "Thomas" == Thomas Goirand writes: Thomas> Sam, Thomas> Is this a real life case (if so, please name the Thomas> package...), or just a pure fictional one, just because you Thomas> love debating? Thomas> Cheers, So, first of all, note that this question has already been adequately answered: * the significant effect on systemd installations criteria is the biggest consideration * compiling twice or turning into runtime configuration are the biggest mittigation. I had at least two situations in mind: Gnome (say policykit) and libvert. They are a bit different. I think your tone is overly confrontational. based on several previous messages, it was clear at the time I wrote the message that it was a real issue. Ian knew that; Simon knew that. Someone else came along and gave a great response (talking about compiling twice). Ian pointed out that I'd missed the significant effect on non-systemd systems criteria, which was helpful to me. I regret missing that detail, but these issues are complex enough we all make mistakes from time to time. Basically several of us all assumed good faith of each other and had a great discussion. You come along a couple of days later and imply that I might not have been acting in good faith and make Debian just a little less nice to be in. Please don't.
If we're Going to Have Alternate Init Systems, we need to Understand Apt Dependencies
> "Ansgar" == Ansgar writes: Ansgar> Adam Borowski writes: >> * dependencies on "systemd | other" rather than "other | >> systemd"; this is a no-op on a systemd system (installed by >> debootstrap before any non-base packages) but causes apt to force >> an init+rc switch elsewhere Ansgar> It's very likely not a no-op on systemd systems as Ansgar> significantly more people somehow got systemd-shim installed Ansgar> than had sysvinit-core, see for example [1] which shows that Ansgar> somehow the "no-op" results in systemd-shim getting Ansgar> installed (which caused problems in the past). Ansgar> Just because you don't observe unwanted behavior happening Ansgar> right now on your system doesn't imply it doesn't exist. Ansgar> And the unwanted behavior that you say wouldn't happen (as Ansgar> it is supposedly a "no-op") happens on a scale larger than Ansgar> the entire sysvinit user base here... Ansgar, you keep bringing this issue up. And it keeps coming up as "Stuff might happen that we don't really understand." That's deeply unsatisfying to hear. And I think it's deeply unsatisfying to you when you hear that people talk about playing alternative games and assuming it's just going to work out. But this issue has kind of reached the level of FUD on both sides. In that it's really hard to respond to "bad stuff might happen," and yet you've also presented evidence that there's something that needs to be considered. I think the way forward is to actually try and get people to explore what the issues are and to write them up for all of us. And once we've done that, assuming that we've done a credible job of trying to research it, trust our conclusions. Yeah, we might introduce bugs and have to revise those conclusions. But saying "something bad might happen but we don't know what," is really frustrating to hear. I do understand it's also frustrating when you keep bringing up a real concern and it is dismissed. have stron If one of the options that promotes alternatives wins, I think it's important to do this work. I think the work would be valuable regardless of which option wins, but especially if we're going to continue to support alternate init systems.
Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
> "Guillem" == Guillem Jover writes: Guillem> The key here, I guess, is that each situation needs to be Guillem> evaluated independently, and no magic decision tree will Guillem> ever fix trying to work things out with other people, in Guillem> good faith, and trying to find solutions or compromises Guillem> that satisfy others and us too. But maybe this is asking Guillem> too much, dunno. :/ Hi. I strongly agree with the above--that things need to be evaluated on a situation-by-situation basis. I'm responding not in the hopes of convincing you or persuading you (or really anyone else). It's obvious that we see the world differently. However, I feel that if I simply said nothing, I would not be respecting the thought you've put into your proposal and to your position. So, I'm responding to say that I've tried to listen and understand where you're coming from, and to show where I think our differences are. Thanks for the work that you put into this. While I disagree, I value what you've done here. My experience in leading groups to consensus is that it is often much easier to focus on specific details and specific situations than on general principles. It is very easy to get people to appear to agree when you are talking about generalities that can be widely interpreted. However, in practice when you go try and apply those generalities to specific cases, you find that the same divisions exist and that the generalities don't help much. There are exceptions: I think the Social Contract has done significant good for the project. In my experience those exceptions tend to be agreements to general principles not born out of conflict, but rather out of a community's desire to define itself. In contrast, when there is conflict, I've found that you get better results focused on specifics. But Guillem is right that as we move forward we'll find things where the specific details we focus on in this GR do not apply. We'll also find cases where circumstances have changed, we have new information, or new ways of thinking about something emerge. At that point, we can (and I think should) start to derive general principles from the specifics we adopt in the GR. I hope we take this GR as the feeling of the project at a single point in time and accept that things will change. I hope that we do not force ourselves to have future GRs to revisit aspects of what we decide in the coming weeks when we can come to agreement that things have changed. I respect that this is an area where people can look at the world differently. Thanks for placing option G on the ballot: if the project believes that focusing on principles is the right way forward here, we now have a way to concretely express that. signature.asc Description: PGP signature
Re: My analysis of the proposals
>>>>> "Uoti" == Uoti Urpala writes: Uoti> I still don't really see why you disagree with my view (not Uoti> exactly a "proposal"). Uoti> Which of these do you disagree with? As someone charged with facilitating discussions within Debian, I'm asking you to stop this thread now. It's obvious there is some lingering misunderstanding, but I do not believe this discussion on -vote will be served by exploring it further. It seems clear that: * There are people here who value being able to use sysvinit. * There are people here who would value Debian deciding not to support sysvinit. * We respect both these views, and deciding among them is one potential outcome of the current GR process. I don't think it was your intention to escalate the situation, but that seems to be happening, and I'd ask you to step back rather than continuing. Sam Hartman Debian Project Leader. signature.asc Description: PGP signature
Call for Votes on the Initit Systems GR
The minimum discussion period lapsed sometime Saturday. So, as one of the authors of a proposal, I ask the secretary to please prepare a ballot and start the vote. As the DPL, I ask the secretary to extend the voting period by a week. I think we've gotten to a point where the existing proposals are in forms that their authors are happy with. Guillem got a chance to author his proposal and to respond to the comments he received. My reading of his message is he's happy with where things stand. This discussion has been really great so far. However, over the last day, the tone has been turning kind of nasty. We've been sniping at each other more. I think there are two contributing factors to that: First, this has been a long process. We've put in a lot of energy, and I think some of us are coming to a point where that is rubbing us a bit raw. Secondly, discussions run through a progression. In the beginning, you get the most dedicated people who are currently available. The people who care enough to make sure they are there. Then as the discussion progresses, you get more people involved. Each round of new people has a cost. You have to revisit things, help catch them up, sometimes reconsider significant chunks of what you have already thought in light of comments they make. The first couple times this happens, we call it additional review from a wider audience. It's essential for doing a good job. Each successive round of people drifting in has a higher cost. Typically each successive round of people wondering in are willing to dedicate less energy, and have less context in what has come before. Some of the costs grow higher. They are more likely to bring up things that are well settled without new insight. The earlier participants know where some of the pain points are, and are more likely to know where to be careful in what they say to be respectful. After a certain point, the people drifting in might have apparently really simple ideas that are unworkable because they disregard the needs of some segment of the community. Hearing these again and again can be harmful. I think both factors are contributing. So, I think we've accomplished what we can accomplish here in this discussion. Continuing the discussion would simply escalate tensions for all of us and I don't think has any probability of significantly increasing the ballot. For those who want a statement of principles on the multiple init systems side, we have option D. For those who want it on the systemd side we have option F. There are some interesting things in option G. I wouldn't be surprised if independent of this GR, people explore whether those options can have some value in our project. Those who believe that the project should not be deciding on specifics, but somehow we should take the statements in G and move forward can vote that way. I appreciate that Ian wishes to have an opportunity to explore other things based on option G. In other circumstances, I might have had a hard decision about whether to wait longer to let that discussion progress. Today, though, Ian's message is contributing to the souring tone of the discussion. > All other options [1] >Lack of an init script is a normal or wishlist bug and >maintainers can block them because they want systemd hegemony. Systemd hegemony is just as loaded as the statements several of us were complaining about last night. Similarly: >Everyone is allowed to use them willy-nilly and non-systemd >support will rot. And again: >Theoretical degradations of dependencies on systemd >systems The mail is actually more disrespectful than that. Ian, who has an excellent command of English rhetoric effectively uses his desire to talk about option G as a reason to summarize what he sees the key questions are. But then he chooses to answer these key questions, and rather than using language respectful to the idea that viewpoints on these differ wildly, he uses the reasonable measured language of fact to describe the options he prefers. Then when describing other options, he continues to use the language of fact, rather than language that admits to other opinions and acknowledges that much of this is his opinion. I know I've warned Ian about this pattern during this discussion. I know others have talked to Ian about similar issues over the years. So, even Ian is contributing to a pattern of disrespectful discourse. I think we've accomplished what we have set out to accomplish: I think we have a very good ballot. Any future refinements come at what I believe is too high of a cost. So I call for votes. --Sam signature.asc Description: PGP signature
Re: Call for Votes on the Initit Systems GR
It was pointed out to me off-list that the constitution says that in calling for a vote I am supposed to say what I think the options are. That feels kind of presumptuous given the work the secretary has done. Kurt and I discussed off list much earlier and he doesn't need me to say what I think the ballot options are. But for the avoidance of doubt, As of the time of this message, I believe that Proposals F, B, A, D, E, and G from https://www.debian.org/vote/2019/vote_002 represent what we've discussed as a ballot. I did not re-read each proposal today, but I did read them Sunday. --Sam signature.asc Description: PGP signature
Re: Proposal to overturn init systems premature GR
> "Ian" == Ian Jackson writes: Ian> 2. The DPL's decision to call for a vote on the init systems Ian> GR is overturned. (Constitution 4.1(3).) This was not a DPL decision. This was a decision of an author of a proposal on the ballot. So I don't think this is a decision that can be overturned under 4.1 (3). For those considering how to respond in thinking about whether to overturn or put on hold my decision to change the minimum discussion period. Please note that what I effectively did is make it so that all amendments are treated the same. Under Ian's constitution, amendments proposed by the author of the GR reset the discussion clock, but other changes to the amendments do not. I used the DPL's powers to make sure that we had a consistent playing field by making it so that like the other authors of proposals on the ballot, I was able to accept amendments without delaying the process. signature.asc Description: PGP signature
Re: Proposal to overturn init systems premature GR
I note that our voting system does have recourse for people who believe that the vote is called to early. They can vote FD above other options. And in this specific case, voting G>FD> other options would send a clear message that we should develop options based on G.
Re: Draft ballot
I don't know if the text should be in the ballot. I did ask someone who has not been in this discussion to review the ballot without the text. They are not a DD. But they found just the choice titles entirely mystifying. But it would be really long with all the text.
Re: If we're Going to Have Alternate Init Systems, we need to Understand Apt Dependencies
> "Svante" == Svante Signell writes: Svante> Jonathan, FYI: From a mail From Uoti Urpala: Svante> https://lists.debian.org/debian-vote/2019/12/msg00054.html That mail had unfortunate tone and several people replied to the thread indicating that the approach taken was not appropriate for Debian lists. >> I don't believe that that kind of tone is welcome on this list. I Svante> Again, systemd versus sysvinit is not the real issue. It is Svante> about systemd versus _any_ alternative. Thank you for this point. It is appreciated, as was your long list of init systems to think about. Svante> And don't talk about Svante> tone, look at this mail list archive, one contribution Svante> quoted above. This however is not welcome, nor was >I've purposely kept out of this discussion, hoping that you all can >behave in a civil manner. Obviously not. I appreciate that you'd like to talk about alternatives other than sysvinit. That's great. We welcome that *if* you can do so in a respectful manner. There are several of us who would be happy to help you figure out how to do that more effectively. --Sam
Re: If we're Going to Have Alternate Init Systems, let's being sensible
> "Svante" == Svante Signell writes: Svante> Nevertheless being Swedish I don't find any offensive tone Svante> in my wording, please tell me where I failed! ( I don't know I'd say failed. Looking back, I definitely think this is a language disconnect and perhaps nothing more. >"behave in a civil manner. Obviously not. It's easy to read that and hear that the discussion as a whole was not civil. I do agree that there have been some elements that have not been respectful lately. But it sounded like you were blaming everyone. Then when you talked to Jonathan it sounded like you were saying it was unreasonable for him to talk to you about tone. Your approach with me was something I like a lot better: "Hey Sam, I don't get it; help me out." Thanks, and thanks again for the list of init systems.
Re: Last minute cominbations G+D and/or G+E
> "Kurt" == Kurt Roeckx writes:
Kurt> On Wed, Dec 04, 2019 at 10:43:53PM +0100, gregor herrmann wrote:
>> On Wed, 04 Dec 2019 17:11:49 +, Ian Jackson wrote:
>>
>> > gregor herrmann writes ("Re: Reframing"): > > So yes, for me a
>> combination of options G and D would be (or maybe > > more
>> accurately: would have been ) helpful in finalizing my ranking >
>> > of the options given my ambivalence.
>> >
>> > To make it concrete I am going to post texts of those two
>> options. If > people come forward to say they support or or both
>> of them I will > formally propose them tomorrow morning (in the
>> hope that the Secretary > and/or the DPL will allow them on the
>> ballot). If you support either > of these options enough, then
>> please formally propose it yourself and > I will second it
>> tomorrow.
>>
>> Thank you for your work on this!
>>
>> I think I would support the G+D combination but given Kurt's
>> mails from this evening [0] it looks like this ship has sailed,
>> and I will now follow your example and spend the time before
>> going to bed with something more enjoyable than reading -vote and
>> thinking the options through.
Kurt> If there is a consensus that new options can still be added, I
Kurt> will consider adding them. As long as I don't sent out the
Kurt> call for votes, things can be changed. But it currently seems
Kurt> unlikely to me, so I'm proceeding in the normal process.
So, trimming a mail I was considering sending earlier.
First, I'd like to thank Kurt for his hard work in dealing with a
difficult election.
I'd also like to thank everyone for a reasonable and respectful
discussion about whether I did the right thing by making a CFV.
Jonathan> On 2019/12/04 09:22, Scott Kitterman wrote:
>> I think short circuiting the discussion process casts into
>> question the legitimacy of the process.
>>
>> I think you are wrong here. How can one know where to rank
>> option G when it's clearly incomplete. I don't know if I like it
>> or not. Let's finish the work on getting the ballot right and
>> then vote.
Jonathan> Absolutely, losing another day to get a proposal right is
Jonathan> a very small price to pay in the grand scheme of things,
Jonathan> where rushing it creates the risk of having to repeat it
Jonathan> all again in the future.
If that were the only consideration, I'd agree with you.
But in my mind, the quality of discussion and the respect for the
participants is a huge huge issue.
I got to a point where I and a number of others thought that the quality
of respect in the discussion--the consistency with our community
standards--had taken a marked turn for the worse.
No one has disputed that. Now, because I write this, someone may pop up
and say the discussion was fine for them.
But several of us did talk about how things were getting worse, and
prior to this message, people have not disputed that general conclusion.
In my mind, keeping Debian a reasonable place to be is a critical
priority. This should be unsurprising to anyone who followed the DPL
campaign.
I've been very transparent about my priorities in this area about as far
back as the systemd TC discussion.
People have complained about cutting off options, but no one has offered
to do the work of moving forward in a manner that maintains the
standards of our community.
No one has offered to stand in and do the work Russ, I and I think a
couple of others were doing Monday, writing public and private messages
to the list trying to facilitate a respectful discussion. No, Russ and
I didn't coordinate, but I think we independently came to the conclusion
that Debian would be better if we tried to remind people of the value of
respectful communication. I cannot speak for Russ or anyone else, but I
viewed that effort as both important and personally difficult.
Today's discussion has actually been reasonably respectful though.
That's great.
So, if there are people who are willing to step in and do the work to
conduct this discussion in a respectful manner, and if the secretary's
work is not unnecessarily slowed, then I would not object to ballot
additions.
I'm not withdrawing my CFV. I will push back strongly on discussion
that is not respectful. I believe it is far more important we start
voting this weekend than that we have additional revisions to the
ballot. But if a new option were to emerge through respectful
discussion, and the secretary were to be okay with it appearing on a
ballot that went to vote this weekend, I'd also be fine with that.
--Sam
signature.asc
Description: PGP signature
Re: Proposal to overturn init systems premature GR
> "Michael" == Michael Lustfield writes: Michael> I find it unfortunate that the call to vote was based on Michael> poor behavior by some individuals instead of being based on Michael> the active efforts of those trying to improve the end Michael> result ( The CFV was not posted to punish anyone. The CFV was posted because I believe (and continue to believe) we had reached a point of diminishing returns. These discussions do have real costs. Ian speaks of how having a compressed timeline forces people to rearrange their schedules. There are also constant costs for the entire timeline for which something like this is open. You need to have people prepared to jump in and facilitate discussions. Many people feel they need to follow closely because the first who respond to new ideas have significant influence over everyone's thought process on those ideas. And as I discussed in the CFV, each successive round of people who wonder along and joins the discussion makes the cost higher in real ways. This sort of thing is expensive no matter how you handle it. And yes, this last week, particularly this last few days has been dragging on. I will be shocked if I find that a significant number of people rank another option between G+D and D. I did contact the most active member of the community team. They made it clear that this conversation was too confrontational and they didn't have emotional bandwidth for that. No, I do not believe the community team was an effective option. I did not contact the community team as a unit in this instance. I have found they are too slow for what we need now when contacted as a team rather than as individuals.
G+D weakening G
I read [1], Guillem's message talking about how he believes the G+D proposal weakens option G alone. [1]: https://lists.debian.org/msgid-search/20191205001617.ga11...@gaara.hadrons.org This puts us into a complicated situation. * If G+D had been proposed and sponsored before the CFV, it's clear that this concern would be moot. * If Guillem had not written that mail, I think we would have reached a point where G+D is on the ballot. * In normal circumstances, after the CFV, option G+D could not be added to the ballot. * If I had not used DPL powers to adjust the discussion period, but instead had simply accepted no amendments, some people would be upset, some people would wish I had not made a CFV, but we'd clearly be in a position where putting G+D on the ballot would be inappropriate. Ian might still have challenged the decision to use DPL powers to put options on the ballot, but I think that sort of challenge would receive even less informal support than the current challenge. * The timing concern is real. People have spoken that theyp do want to start voting soon. Several people have indicated that they do find this is dragging on. * The giving people time to put all options on the ballot concern is real. Others have spoken and indicated that they value taking a bit of extra time (as in a couple days starting at Tuesday) to get the right options on the ballot. * Others have indicated they would be willing to push things much further out to get the right options on the ballot. That's a much smaller number. * Many people have indicated happiness with the ballot Tuesday. * I cannot remember whether we've seen anyone indicate that another option would be between D and G+D in their rankings. I'm not sure what to do. I'm sure that in my mind pushing things past Saturday would be a bad idea. I will continue to work to avoid that. I think that the ballot Tuesday has broad support of the people involved in this discussion. I understand there are a few who disagree. I'm not unsaying anything I said yesterday. I am asking everyone to think about whether G+D on the ballot is really fair to option G. Ultimately I think this is up to the secretary. If there is anything I as an individual or as DPL can do to support any decision the secretary makes about the handling of G and its combinations that does not push the start of the vote back, consider this mail to have done so. signature.asc Description: PGP signature
Re: G+D weakening G
>>>>> "Matthew" == Matthew Vernon writes: Matthew> Sam Hartman writes: >> I read [1], Guillem's message talking about how he believes the >> G+D proposal weakens option G alone. >> >> [1]: >> https://lists.debian.org/msgid-search/20191205001617.ga11...@gaara.hadrons.org Matthew> Later in that thread ( Message-ID: Matthew> <20191205121800.ga75...@thunder.hadrons.org> ) Guillem Matthew> explicitly rebuts the suggestion that they are unhappy Matthew> about G+D appearing on the ballot: Matthew> " Just to clarify, and to avoid any possible reading of Matthew> subtext implying I'm unhappy with the combination in the Matthew> new proposal: " Ah, reading that message for the second time, I agree with your intrepretation. It was less clear to me on first reading.
Re: G+D weakening G
> "Matthew" == Matthew Vernon writes: Matthew> Do I assume correctly, therefore, that you now agree that Matthew> G+D should be on the ballot? I'm not going to stand in the way. I think everything I wrote in my message is still true, including that I think the secretary is in a better position to judge than I am. I think one additional thing is true that I was not sure of earlier. Guillem doesn't object to it being on the ballot. had I been sure of that I would not have written a message this morning. I'm sorry that I'm being equivocal. But when I ask myself "Sam, do you agree that G+D should be on the ballot," the answer is neutral not yes. If I had to take some action to get it on the ballot, I'd take that action. But I've already effectively handed that off to someone else. Right now I'm well into I'm done; I don't care; please can we vote. --Sam
Some thoughts about Diversity and the CoC
TL;DR: Treating people with respect is hard and very contextual. Choosing to change how you talk about something to make people more comfortable doesn't always mean you were obligated to make that change. Sometimes you're just promoting connection. > "Scott" == Scott Kitterman writes: Scott> On November 27, 2019 2:54:04 PM UTC, Simon McVittie wrote: >> On Wed, 27 Nov 2019 at 11:27:13 +, Chris Lamb wrote: >>> May I gently request we replace the use of the word "diversity" >>> throughout the "init systems and systemd" General Resolution >>> prior to it being subject to a plebiscite? >> >> Thank you for raising this, Chris. >> >> I agree. I have been uncomfortable with this in the context of >> "init diversity" efforts, but I didn't raise it in the past >> because I couldn't articulate clearly why I felt that it was a >> problem. Since it's now on-topic, here's my best attempt at >> >> I would hate to see diversity and inclusion of people (the >> meaning of the word used in the name of the Diversity Team) >> harmed by creating a perception that the term "diversity" has >> been devalued by stretching it to encompass technical >> preferences, because I think diversity and inclusion of people is >> much too important to let that happen. Scott> I am deeply saddened by this message. I think it is entirely Scott> misguided, but I fail to come up with a way to explain it Scott> that is no one will think violates our code of conduct. It's Scott> things like this that are causing me to start to view it as a Scott> mistake. Scott, let me take a crack, because I too was deeply conflicted by that message, especially as I think about the CoC. First, there's a sense in which I agree with removing the term diversity. It's clear that Simon's message represents a position that resonates with a number of participants in the discussion. Those people are in effect saying "We'd feel more welcome in this discussion if you'd change the term. Also, it might make it more likely your preferred option is selected." The people using the term diversity thought about it and decided that they did want to be more welcoming and probably even that they agreed with the political analysis. So they proposed changing the term. That's great. The CoC encourages us to listen, and to show respect for others. And I think considering changing the framing of the discussion to include people is a great thing to do. The emphasis is on *considering* (and of course when you consider and conclude it is a good idea, doing). So in this instance, based on what we saw in the discussion, I think the term change is great. We've seen a trend that there are a number of people who are uncomfortable using concepts like diversity, war, censorship, and free speech that are globally loaded as part of analogies in a Debian and free software context. As I understand it, the CoC says we should consider these needs. But others actually value those analogies. No, Debian is not a government. Moderating content we distribute is not the same as government censorship. And yet, Debian has power in the world. And some of those analogies have power because members of our community would like to see Debian as a force for freedom; they would like to reflect values both globally and locally. And so they find using the same words powerful in both contexts. We exclude them by denying them their analogies; that has a cost. That kind of exclusion can be disrespectful. It's a balance. Just because following the principles in the CoC, we change our terminology does not mean that was the only reasonable thing to do. In some situations, we also could have been respectful by acknowledging the concern, considering it, understanding why we make a choice that makes some uncomfortable, and continuing to make that choice. "Hey, we're not trying to be jerks by talking about freedom of speech. We hear and acknowledge the difference you're pointing at, but this analogy allows us to celebrate something that is important to us." There are limits. If you're in a one-on-one conversation and I've pointed out that I find your termonology uncomfortable, you're probably being disrespectful if you don't shift in that conversation. I might well be being disrespectful if I keep asking you to change your terminology in a setting where people value it. If you are using the terminology to provoke and escalate conflict rather than to call out something you find good, then we might well need to change the terminology even if you wish we didn't. As an example, because of some of the specific examples, and the other attacks, talking about things in terms of censorship on debian-project early this year *was* problematic. In contrast, I think that you can talk about weboob in terms of censorship if you acknowledge there is a difference between Debian and a government in that instanc
Re: Some thoughts about Diversity and the CoC
> "Scott" == Scott Kitterman writes: Scott> TLDR: Words have meanings and I find it deeply offensive when Scott> one group tries to hijack them for their own ends. This Scott> entire discussion makes me less comfortable with Scott> participating in Debian. I agree that happens sometimes. I agree that's even happened in Debian. I really don't think it happened here. Simon did not try to narrow the meaning of diversity. He talked about why people might not want to use the word. And (this is key), the *other side agreed*. Listening to someone, hearing their concern and finding there's a way to meet your needs and theirs that both sides are happy with is in my opinion not hijacking. --Sam
Re: Some thoughts about Diversity and the CoC
>>>>> "Gerardo" == Gerardo Ballabio writes: Gerardo, somehow you've taken the discussion from terms used in Debian elections to abortion politics and use of people's preferred pronouns. You could have found examples from within a Debian context. They were right there: diversity and its use in init systems. You did not need to choose politically loaded examples for topics that don't really belong on -project (and certainly not -vote). But there's one aspect of this I need to explicitly respond to. I understand and support Steve's anger at your message. But to be crystal clear: >> >> For example (forgive me if this might seem off-topic, but I think >> that working out the details of an actual example is necessary to >> make my point clear), I do not feel that I should acknowledge >> people's requests to refer to them by their "preferred >> pronouns". That is because I believe that people's sexual >> identities are determined by objective facts, such as which >> chromosomes are there in their DNA, and not by how they >> subjectively "perceive themselves". So when I refuse to refer to >> a person with XY chromosomes as "she", or to abuse the English >> language by calling an individual "they", in fact I am defending >> my world view, and you must not deprive me of that right. In adopting the Diversity Statement and the Code of Conduct we've committed to welcoming people to the project regardless of how they identify the project. Welcoming people includes respecting their preferred pronouns; people cannot be welcome if we are misgendering them and causing them to feel alienated. Striving to use the appropriate pronouns is a requisite for being welcome in this community. It's not always easy, and we all make mistakes. But intentionally choosing not to use someone's preferred pronouns is inconsistent with the respect demanded of the Code of Conduct. Debating whether people get to have preferred pronouns or whether things like singular they are appropriate in the English we use in Debian is off-topic for Debian discussion fora. To the extent that such debates were useful, we've already had them many times. Sam Hartman Debian Project Leader signature.asc Description: PGP signature
Re: Some thoughts about Diversity and the CoC
>>>>> "Sam" == Sam Hartman writes: Sam> In adopting the Diversity Statement and the Code of Conduct Sam> we've committed to welcoming people to the project regardless Sam> of how they identify the project. Sigh. This should have been regardless of how they identify themselves.
Re: Some thoughts about Diversity and the CoC
> "Scott" == Scott Kitterman writes: Scott> I think you reinforce my original point. In this case, the Scott> 'other side' isn't the proposer of the option, it's me. Scott> What I'm hearing is that the CoC isn't for people like me Scott> because you are completely dismissive of my discomfort. Given that Simon has his preference, what would you prefer to have happened? Are you saying you wish there were options on the ballot both with and without diversity? Are you asking for your concern to be acknowledged, but perhaps not for some other change? How would you like for us to value both Simon 's position and your concern? These are serious questions. I don't want to be dismissive, and I understand how it might come across that way.
Re: DPL vote timeline
The timeline seems off by a year, but otherwise lgtm. As I mentioned on -private, I'm going on vacation 2020-02-21 through 2020-02-28. I will make a decision about whether I'm going to run again on that vacation and let folks know before the nomination period starts. --Sam
Opposite of a Platform for DPL 2020
TL;DR: Overall, being DPL has been incredibly rewarding. I have enjoyed working with you all, and have enjoyed the opportunity to contribute to the Debian Project. I hope to be DPL again some year, but 2020 is the wrong year for me and for the project. So I will not nominate myself this year, but hope to do so some future year. I wanted to take some time to share my thoughts on my time as DPL, and some thoughts about the next year. Over the past year, we've done some great work. I'd like to start by acknowledging that and taking a moment to be proud of our accomplishments together. Consensus And Summaries: DH and Git === In my platform I wrote: Debian is not fun when we face grueling, long, heated discussions. It is not fun when we are unable to move a project forward because we cannot figure out how to get our ideas considered or how to contribute effectively. Much of my focus at DPL was on a couple of experiments in decision making. Together I hoped we could show ourselves and the world that Debian can make decisions. I wanted to explore the DPL's role in accomplishing that. We succeeded. I facilitated a number of consensus-based discussions where we explored options and came to conclusions. In my mind the major elements of these were: * Starting with a statement of the problem area and a set of questions/observations about the current state of the discussion. * Giving people an opportunity to give input. * Indicating areas where we appeared to have an answer and areas where additional input was required; trying to cut off threads that were starting to repeat themselves. * Providing a summary so others could check that we got to the same place. * Feeding results of the discussion to the appropriate parts of the project. I think we succeeded at this work a number of times. From my standpoint, it was rewarding and energizing to see us actually make a decision and to get to a place where I thought we were not just repeating ourselves. For me and a number of other contributors I've talked to, discussions are less draining when we reach conclusions. I think I demonstrated that the DPL can be valuable in facilitating these discussions. I'm glad that I was able to explore more ways that the DPL could help the project. But what really made me happy is watching others copy this pattern. Yes, the DPL can facilitate, and for some project-level discussions that is the right answer. But anyone can implement the above steps. I saw a number of people do so. In particular, I think summaries at the end of discussions are incredibly important. It was great to see others doing that. It's great to see us learning together. This was an experiment. While I think we demonstrated that we can use this procedure to make decisions, we also brought forward a number of things to think about for the future. The biggest issue is that these discussions do take time and energy even when they eventually reach conclusions. I think we need to think carefully about when we need to make decisions as a project, or when other approaches are better. Also, one or two people can cause a consensus discussion to drag on much longer. As an example, it was obvious to me as a facilitator very early on in the Git Packaging discussion that we were not going to change our position on the use of Gitlab and other non-free services. Hundreds of messages were spent on a sub-thread that was never going to reach consensus. We need better tools for managing that use of our collective time while allowing each other to be heard. I think both of these are great areas to explore as we continue to improve Debian decision making. Facilitated GRs === In my platform I talked about how I thought the DPL's power to propose general resolutions could be used as a tool for facilitating discussion when consensus cannot work. We explored that together, and I think we did a great job of breaking a longstanding block in how we approach init systems. The traditional wisdom is that GRs should be proposed by a strong proponent of the option in question. I was dubious of this wisdom. It starts the process out on a confrontational note, rather than as a cooperative exploration of what the project wants. When consensus is impossible, there is inherent conflict. However, we can (and did) work together cooperatively to enumerate the options. I believe doing some ground work as a facilitator behind the scenes helped make that easier. There's another benefit though. By working to facilitate, I was able to hear options in the middle expressed by people who had opinions, but who were not involved enough to dedicate their time to go put that option forward. In this instance, that sort of compromise--collected from comments of bystanders rather than entrenched parties--won. Yes, there are dangers to compromise, but there are also dangers to only selecting from the positions on the edg
Where are the High Energy Low Conflict Projects
>>>>> "Brian" == Brian Gupta writes: Brian>On Wed, Mar 4, 2020 at 2:32 PM Sam HartmanBrian>Sam, Thank you for your work as DPL. I just want to add Brian> one thought about your takeaway that maybe the project isn't Brian> ready for a "high-energy DPL". I don't think we should Brian> discourage folks who have "high-energy" and free time to work Brian> on Debian (as DPL). I didn't want to discourage anyone. My personal take away is that if you are doing a bunch of high energy leading and facilitating, you need to have a way to do what you say below. Brian> Everyone working on Debian just needs to Brian> always remember that there is common ground, and we need to Brian> work around the areas of conflict. In other words "pick your Brian> battles" (carefully), because we as the Debian family have Brian> some strong common bonds, and it's a shame to break or damage Brian> those bonds. The challenge is that to do this work you need everyone else to buy into that idea too. It's not enough that you see the common bonds and work toward them. The other people in the project need to see the same common bonds. And that just doesn't happen. My take away is that since that doesn't happen in practice, you need to have some way to help people see the common bonds and to deescalate things when there is disagreement about where the commonality is. It's possible that someone else with a lot of energy will have a different way of looking at this problem that allows them to make progress. That's great. Brian> There is so much work that we could be doing Brian> that we don't have time for, that aren't "battles". For Brian> example, I don't know what happened to "Debian PPAs"? As I Brian> understood, there was a broad consensus that this would be a Brian> great thing, but no one had time to do the work. I'd love to Brian> see a motivated DPL, come in and "make it happen". (It Brian> doesn't need to be a DPL, but this is just one example.) Ppa without battles? See, there are people working on this problem today, but it's one of the most embattled areas of the project. It's precisely the sort of area where the interests of people doing the new work run up against challenges from existing teams. No, no one is working on the specific design that people came up with for Bikeshed back in 2011 or whenever. The world changes; new tools come along that can make solutions easier to develop. One of the things we've learned is that PPAs aren't really about being able to dput to some repo that isn't quite Debian. Even on Launchpad, if you use PPAs a lot, you quickly learn that isn't the best approach for what you want to do. You want to be able to commit to a repository somewhere and have Debian packages pop out the other end. Perhaps not everyone wants this, but it's a common enough goal that it quickly interests anyone working on the problem. So, on the Launchpad side, you end up either using their existing recipe system, which does this for you. Alternatively you end up developing your own tooling which somehow, on a regular basis prepares source packages (almost certainly from a repository) and dputs them to a ppa. On the Debian side. If you are willing to develop your own tooling, then we've actually got most of the components. Between mini-buildd, reprepro, custom instances of dak, aptly, pbuilder, and sbuild, we've got a fairly good kit for people who don't mind writing their own tooling. I'm probably forgetting some of the tools there. But if you want integration with repositories, especially if you want integration without writing a bunch of your own tooling, then it turns out we're also doing work. It looks a lot more like Salsa CA, tag2upload, fastrack.debian.net, and related technologies than it does the classic Bikeshed design. Why is that? * Our requirements have changed. It's not good enough to just produce a repository. We live in a world that values CI/CD. We want to run tests against our repository--piuparts, autopkgtest, lintian and friends. * The rest of the world has developed technologies for doing this sort of automation. It's a lot easier to code to .gitlab-ci.yml, containers, docker, etc than it is to code to Dak, wana-buildd and tossing around a bunch of source packages. * Prototyping away from the core infrastructure allowed people to move faster in part because they were not involved in the teams that had a justified culture of being conservative. And yet we're seeing significant friction with the last 10% of these projects (you know that same last 10% that takes 90% of the time). The Salsa admins a
Typically self-nominations are short
I'm concerned that by sending my longish message about why I am not running, I may have started a trend that I do not value. Typically the nomination messages are fairly short. I appreciate Jonathan's thoughtful message, but you don't need to write something that long at this stage, and shouldn't be held to his high standard. By Saturday, you need to know that you are going to run and let the project know that. We can talk about whether I was wrong to post a long message before nominations started, but this list and this time are probably not the right place for that. --Sam
Question to Brian: Why do you need to be DPL to set up foundations?
Dear Brian: I've just read your platform. For reasons that are slightly different than the ones you state, I tend to agree that setting up foundations sounds like a good idea. And I think you have a significant chunk of the background to lead that effort. As an individual (read after my DPL term expires) I'd be very likely to sponsor a GR as a referendum on this idea and even include text delegating making it happen to you. But I can't figure out why you'd need or want to be DPL to do that. How would you handle the aspects of being DPL that are not related to setting up a foundation? You talk about bringing back a DPL helpers team. What would that give us that we don't have today? How would you lead over the next year in areas unrelated to setting up the foundation? What do you think the big challenges that the DPL will face that are unrelated to the foundation/administrative matters will be in 2020? signature.asc Description: PGP signature
Why I think We Probably Want a foundation
TL;DR: I think Debian probably wants a foundation for legal protection. I think doing this as a DPL platform is all sorts of wrong. I'm speaking as an individual, although my thoughts are influenced by my time as DPL. Hi. I've generally been coming to the conclusion that we probably need to have a foundation, but my reasoning is different than Brian's. I'd first like to address our relationship with SPI. Martin asks why DPLs haven't been attending the SPI meetings. For myself two reasons. First, I never thought of doing so. If it makes it way into the DPL hand-off notes as something to consider, then I probably would have at least shown up and introduced myself. Honestly, though, from the DPL standpoint I am not at all sure the DPL really needs to get involved. Presumably Chris did attend the SPI board meetings at least once he was elected to the board:-) When I look at http://spi-inc.org/corporate/board/ I see a lot of familiar names. Three of the five board members are clearly heavily involved in Debian. And I think I've seen a couple of those officers around too in my Debian work:-) So if Debian has some concerns to work through--and we do have a couple--we can and should bring them up with the SPI board. My interactions with the SPI board fall into one of two categories: 1) When I've asked for achievable things or given feedback, I've gotten reasonably prompt answers. 2) balls got dropped. As an example we'd like to understand the implications of a SPI project working with/taking money from Huawei. That's complex and the board dropped my question with no answer. I believe a couple of others also asked this question. I'll write to -project separately about the handling of DebConf donations. My big concern is legal liability for people contributing to Debian. I understand that to some extent I'm bringing up an issue that has been making the rounds on certain blogs. I'd like to think that I and we can discuss it more constructively here. What we tell ourselves is that Debian has no legal existence. We're part of SPI, and so we hope that we'd have the same protections as volunteers working for any non-profit. When representing Debian and SPI, the Software Freedom Law Center is very careful to advance this argument as much as possible. But there are alternative ways to look at things. At Libreplanet 2018, I was talking to a lawyer (not receiving legal advice--just a hallway conversation) who I respect. He said that if he wanted to go after Debian, he'd argue that we are a non-incorporated association. That might well mean that all our leaders are liable for all the actions of Debian. I'm not a lawyer. But if someone wanted to make that argument we'd have a fight in court as each individually named defendant tried to argue that they were just acting as a volunteer on a SPI project and tried to get the case dismissed against them. That sounds kind of unfun. There have certainly been things I've done as DPL where I really wish I had better confidence that I am a volunteer for an organized non-profit. I'll certainly note that Debian as an unincorporated association is a lot easier to understand than some more complex story. Perhaps if Debian were just a SPI project it would be easy to explain. Except what about Debian France? Are we a SPI project that happens to have assets held by Debian France? Why would we do that if we're a SPI project? Or are we somehow a SPI project *and* a Debian France project? But wait, how can that work. Recently, SPI introduced Debian to another lawyer. Now even SPI is advancing the idea that Debian has enough independent existence: the vice president recommended that I sign an agreement on behalf of Debian while SPI signed an agreement on their behalf managing any potential conflict of interest that might come up. I think I'm going to be able to avoid that situation and leave it entirely to the next DPL. I'll say that if Debian is legally just part of SPI, it doesn't make sense for Debian to be signing agreements with itself. If Debian is more than just part of SPI, I want that more to be a kind of legal entity that has protection for its officers and volunteers. I don't want the separation between SPI and Debian to be a way for counter-parties to attack us as individuals. And while we're at it, some insurance would be really nice. While working in the IETF, I had insurance. If I made a mistake as a working group chair or IANA expert--let's say related to a patent matter or some antitrust matter--there was insurance to help defend my actions. As DPL, there's no insurance at all. There's no insurance if ftpmaster members make an error around copyright, or if DAM or other parties make an error. Yeah, insurance costs money. It's not clear that Debian's recurring income supports getting the insurance I wish we had. But yet, if we went to our community and demonstrated we would spend that money to prote
Re: Question to all: Outreach
Speaking as an individual. > "Jonathan" == Jonathan Carter writes: Jonathan> On 2020/03/19 12:39, Paul Wise wrote: >> On Wed, Mar 18, 2020 at 9:54 AM Jonathan Carter wrote: >> >>> My honest answer? Yes, it would be nice if all the delegates >>> could be project members, I understand your concern, but often >>> it's best to be willing to work with people who are willing to >>> do the work. >>> >>> I would suggest some minimal vetting for outsiders who become >>> delegates, for example, just like when someone gets access to >>> Debian machines have to agree to the DMUP, delegates should >>> agree to uphold our community standards (like the CoC for >>> example). >> >> I think if we can trust them to be delegates then we can trust >> them to be Debian project members. For most potential delegates >> who aren't yet members, I assume the non-uploading DD process >> would be minimal enough. Jonathan> For sure, going through the non-uploading DD process Jonathan> should remain a bare minimum for someone who wants to Jonathan> become a project member. You seem to be dodging the question a bit. Paul is talking about the link between delegate and member. You are focusing about the link between non-uploading process and member. I realize it's convenient to focus on that link because it's the side of the equation that is less controversial, but it isn't really the area Paul and Enrico have been asking about.
Re: DPL blindsides
> "Teemu" == Teemu Hukkanen writes: Teemu> Would you, in a situation like this, commit to providing the Teemu> information before becoming DPL in order to avoid a conflict Teemu> of interest? What is the conflict of interest you see here?
Re: DPL blindsides
I'm sure people unfamiliar with this situation are horribly confused by this point. As DPL, I think I have a duty to try and give the electorate enough information to evaluate situations like this while retaining privacy and neutrality. I'm going to try and do so. My understanding is that in early 2017, some rather public and concerning accusations were made. As DebConf17 approached, the DebConf local team made a decision that Teemu disagreed with and protested. For a while, the Debconf team failed to respond to Teemu's protest. The DPL at the time escalated and asked for them to respond. They did, declining to engage in a discussion because of the sensitive nature of the situation, but pointed Teemu at another team in Debian. Jonathan was copied at least on the mail where the local team declined to engage further, but I suspect that was in his role as a DebConf Committee Member. According to Jonathan's mail here he was not involved in the decision in question. Moreover, according to mail from another DebConf committee member, the decision is one that the local team took without involving the DCC as a whole. All evidence I have supports Jonathan and the DCC's claim that they were not involved. However, I have not explored exactly who did make the decision. The DCC wishes that they had been involved earlier in the process. I'll note that this is the kind of decision that is often taken in a very small group, and I think it would be reasonable either to involve or not to involve the DCC at the choice of the local team. (I suspect some DCC members will disagree with me). Around the time Teemu brought up this issue on debian-vote, he sent mail to the current project leader as well as people involved in the previous exchange, asking for help deescalating the situation. His proposal for how to do that seemed like it was going to be an escalation rather than a deescalation. I responded with an alternative, describing the situation under which I thought it made sense to go forward and describing what a deescalation might look like. I have received no mail sense then. --Sam signature.asc Description: PGP signature
Re: [draft] Cancel this year's in-person Debian Developers Conference DebConf20
Hi. I think there is a lack of precision in the text of your GR that I find highly problematic. I suspect it will be fairly easy for you to correct this and possibly even gain my support, so I'd ask you to look for ways to do so. You say that the WHO has declared Covid-19 to be a pandemic, and has not lifted that declaration. I doubt they ever will. I think that covid-19 will always have been a pandemic. The interesting thing is what the WHO says about travel and minimizing international travel. so, I'd ask you to 1) focus on recommendations about travel rather than focusing on whether Covid-19 is or is not a pandemic. 2) cite specific recommendations on travel as reasons not to have a conference. 3) If you cannot easily find specific recommendations against travel to conferences, then do significantly more leg work justifying your position. Thanks, --Sam
What does Israel/Local Authorities say about DC20?
[I hope someone on the DebConf team side is willing to summarize the results of this discussion to debian-vote] > "Stefano" == Stefano Rivera writes: Stefano> Hi Sam (2020.05.22_14:51:42_+) >> The interesting thing is what the WHO says about travel and >> minimizing international travel. Stefano> I was surprised that it doesn't try to dissuade the events Stefano> entirely. What it does say is: 1. Work with your local Stefano> authorities. 2. Have a plan for dealing with an outbreak Stefano> at your event. In the mail opening registration, there wasn't any discussion of having talked to Israel/the local authorities about the conference. There was only an assertion that it looked like things might be okay. 1) To the extent that we have contacted the local authorities it seems like it would be good to write up the advice we have gotten. 2) It sounds like the advice from the WHO is to work with local authorities. It seems like we really ought to follow that advice and reach out. I'd go so far as to say that holding a conference without good contacts to local health authorities and good lines of communication/support would be irresponsible. Now, for all I know that's in progress or has already happened. 3) Once we do get advice (or now if we already have that advice) I think that would be valuable input to the debian-vote discussion. signature.asc Description: PGP signature
Leading Debian
> "Raphael" == Raphael Hertzog writes: Raphael> With that said, there could be many questions to be asked Raphael> but I will concentrate on three: Raphael> 1/ Why have you all given up on the idea to lead Debian? It Raphael> seems to me that you are happy with the DPL being a Raphael> super-intendant and nothing more. Pandemic, man! I have a certain amount of experience trying to lead Debian, and it's not the year for it. First, leading Debian responsibly is hard. The DPL's job is not to advocate for a specific technical direction. At most, the DPL can pick some areas where change is needed, find out (or confirm) relevant stakeholder consensus, and move in that direction. My first term, I was trying to illustrate process as well as accomplish change. And so, I worked on building project consensus. As we saw, that was very high energy. A DPL could lead in smaller ways--working on finding/confirming consensus in smaller groups. Even that's going to be relatively high energy, and if consensus proves hard to find may easily spill into a project-wide discussion. I don't think now is the time when we want to spend that kind of energy. I don't think I'm the only one who is still healing from the pandemic. Yes, I'm going through a lot of change, but it's all personal. Finding safety and community again. What I expect from the communities I'm already part of is as much stability and support as I can get. I don't want extra change. The world's throwing that at me just fine on its own. to the extent there's changeit is going to come in small ways like figuring out how to have community in an online world. (the mini debconfs and stuff like that). But I'd also like to quibble with one thing. Improving recruiting is leading Debian. I think it is one of the most important things we can be working on now. It puts us in a position to be able to sweep up and welcome people jostled around by all the change in the world as they come within our sphere of influence. In my mind hearing that part of Jonathan's keynote last year was really exciting. signature.asc Description: PGP signature
Re: How to leverage money to accomplish high impact Debian projects
Adam, I think a more respectful way of including trans members of our community would be to count them as the gender they identify with (assuming you know). You'll still end up with a category for nonbinary of course.
Re: Should the project hire one or two persons to help the DPL?
You asked if DDs would support the DPL hiring people. So I answer as an DD. > "Raphael" == Raphael Hertzog writes: Raphael> * it means that the DPL can organize the administrative Raphael> work so that it ends up on the shoulders of paid staff, and Raphael> the DPL can take a more active role in leading I think spending money on accounting, legal, and other administrative functions sounds great. I don't have a problem paying people to do this or paying organizations to do this. We already pay TOs (to do work for Debian (our larger TO takes a percentage of donations); we already pay lawyers; some TOs pay accountants. I see no problem with Debian spending more money directly if it benefits us in this regard. There was discussion last year of a Debian foundation. I think there are lots of issue to work through there, but I think there is good that can come of that proposal. Raphael> * it means that the DPL can direct workforce in areas where Raphael> they believe work is needed (like good documentation for Raphael> beginners, like coordinating with a contractor to have a Raphael> good introductory video or better looking website, like Raphael> finding useful projects to submit for funding to Freexian Raphael> ;-)) Um, no. Money is power. The DPL should help the project achieve its goals. The DPL should not use the project's money to achieve their own personal agenda. Having the DPL unilaterally spend someone's time on documentation, videos, etc would really mess up our power balance. That said, some of those functions are distant enough from developing an OS, I'd support a delegated team asking for money to hire someone. As a specific example, if we had a team that wanted money to produce a introductory video I'd support that. In my mind the distance from the DPL would be key in making that appropriate. signature.asc Description: PGP signature
Re: How to leverage money to accomplish high impact Debian projects
> "Gunnar" == Gunnar Wolf writes: Gunnar> In my case, fortunately my livelihood is guaranteed, and Gunnar> depending on many things, I will have more or less time Gunnar> available for the projects in Debian I most care Gunnar> about... Adding money offers to the mix won't change the Gunnar> results. For me that's true up until the point where I can make most of what I'm making from my day job on Debian or other FOS activities. Which is to say there's a boundary condition. On one side of that boundary, money doesn't motivate someone who is professionally employed. on the other side, enough money allows someone to consider a career change. I think some of us would jump at that if we could. --Sam
Re: How to leverage money to accomplish high impact Debian projects
> "Russ" == Russ Allbery writes: Russ> This is a deep structural problem that we're going to struggle Russ> to solve with modest changes such as increased efficiency to Russ> try to make our scaling more sublinear, or increased Russ> recruitment (of still primarily unpaid volunteers). There is Russ> more happening than before, and we're struggling to keep up, Russ> let alone get out in front and lead. This is due, Russ> fundamentally, to a lack of resources, and it's hard for me to Russ> see how we can close that resource gap while still being a Russ> volunteer project (nor do I want us to stop being a volunteer Russ> project). For example, one obvious way to get a similar Russ> scaling of resources would be to change from being a volunteer Russ> project to being an industry consortium with paid staff so Russ> that we can be the recipient of that increased corporate Russ> spending. But I highly doubt most Debian Developers (myself Russ> included) have any appetite for that. I'm engaging because you seem to have ignored an option that is obvious Russ> at least to me given the discussion this all came out of. I'm wondering if you have any interesting thoughts so I'm asking. I'm not trying to be confrontational or to disagree with anything Russ> you've said, just wondering if there are things we all can learn from considering more. I'd like to ask you to look at the elephant in the room. This conversation came up specifically because we were talking about an organization loosely associated with Debian paying some Debian developers. Yet, you didn't consider any of the middle options in your analysis--only the option of staying effectively all volunteer or going all industrial consortium. do you have any thoughts on the middle options like having industrial consortiums that we work with so that Debian developers who are comfortable in that model can pursue that?
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
> "Steve" == Steve Langasek writes: Steve> Text of GR Steve> The Debian Project co-signs the statement regarding Richard Steve> Stallman's readmission to the FSF seen at Steve> https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md. Steve> The text of this statement is given below. Seconded. My second also applies is the word board is inserted after FSF above. signature.asc Description: PGP signature
Asking DPL to shorten Discussion Period for rms-open-letter
I suspect that the issues surrounding the open letter asking rms to step down and for the FSF board to resign are fairly well understood at this point. It's been an ongoing issue. I don't think we're going to get much benefit out of a prolonged discussion, and I think that there is significant benefit in acting quickly in this instance. So, I'd like to ask the DPL to consider shortening the discussion period. It's possible that circumstances may arise requiring more than a week's discussion. But unless that happens I think we would all be happier spending less rather than more time on this issue. I suspect most people already have their minds made up. signature.asc Description: PGP signature
