Re: [all candidates] how to choose Jessie init system
On 2013-03-18 15:55, Stefano Zacchiroli wrote: How do we make an inherently archive-wide technical decision when multiple, possibly equally valid solutions do exist? (I think the latter part, the existence of alternatives, is particularly important here, as we have well-established approaches for other cases. For instance, when one of the alternative is clearly superior, we usually apply some sort of "Debian's Darwinism": we wait for it to be popular enough, we make it increasingly more mandatory in Policy or the Release Team pick it as release goal, we do NMUs, etc.) 1. Communication before decision-making Problems in making decisions often come from the early stages of the relevant discussions. For example, this can happen if the early discussion didn't include all the stakeholders, so that some feel excluded, or because it launches straight into nitpicking of alternative proposals before they are fully-formed. In any discussion that starts by people directly arguing what the conclusion should be, few of them will back away from their publicly stated positions later on, even if facts emerge that would have otherwise led them to a different conclusion. Openness In Debian, people can't be *forced* to involve themselves in a discussion where they're a stakeholder, but it helps to make sure it is on the right list, that it's not buried in the middle of an unrelated thread, and that relevant people are pinged if they don't speak of their own accord. When someone wants to move a specific topic forward, it's often better to explicitly call for opinions and ideas before announcing their own proposal -- and, of course, they should try to be genuinely open to ideas from others. Or already at this stage they can recruit someone neutral (which could sometimes mean the DPL) to do this and coordinate the discussion process. Communication Nitpicking is natural in online asynchronous discussions, but we can still try to avoid this taking over the discussion. It can help if people actively discourage comparing alternative proposed options with each other at all in the initial phases of discussion, and instead encourage people to help improve the content and form of each proposal separately. It is better if each proposal is first challenged in isolation, to see if it covers the necessary details, has a sufficiently good transition plan, etc., before discussion moves to comparing the proposed options with each other. Once there is, for example, a wiki page describing each proposal that e.g. includes enough detail and has a good transition plan, people can constructively move to comparing the alternatives, hopefully keeping questions of technical superiority separate from debating the actual form of the proposals. But still, rather than free form discussion, it may be better to compile in the wiki lists of arguments for and against each proposal. And the intention should be to make the descriptions better, rather than to win an argument -- people should try to list the disadvantages of their own proposals, and the advantages of others'. Transparency When there is reasonable agreement on a set of alternative proposals, and on arguments for and against each, there can still be significant disagreement on how to weight the different factors and reach a final decision. But any decision reached at this point is likely to be much more informed than one made through a discussion where people publicly took sides and argued loudly for their preferred option from the start. 2. Decision-making for system-wide choices Firstly, in this kind of debate I don't think the DPL should argue for or against specific solutions, but should seek to push discussions forward neutrally, trying to make them progress usefully towards positive conclusions. For any technical decision, it's certainly not the Debian way to choose a new tool merely because its features sound promising or because people are arguing loudly about how some options might or might not work. Even for something where only one choice will be implemented widely, I would expect to see a test implementation of each proposed option before one is chosen. In some cases this will be in packages in the main archive; in other cases it may require a forked copy of some packages. (Better PPA-type infrastructure, and more standardised VCS workflows, could help here.) Often, there will be a clear consensus winner by the time that working implementations are ready, at least among the major technical stakeholders. In many cases the release team can push progress on a transition, or the d-i team can decide to switch new installations to a new default. In these kinds of cases the DPL and others may be able to help discussion along, but shouldn't seek to take ownership of it. In a few cases, there will be no consensus winner, for example where technical and non-technical preferences clash. Or we may
Re: [all candidates] how to choose Jessie init system
Gergely Nagy writes: > Stefano Zacchiroli writes: > >> Some of the longest -devel thread in recent years have been about >> Debian's (default) init system: SysV, SystemD, Upstart, OpenRC, etc. >> Despite folklore, I don't think those thread have been (entirely) >> trollish, they all hint at a concrete problem: > > (For the record, it's systemd, not SystemD. Sorry!) > >> How do we make an inherently archive-wide technical decision when >> multiple, possibly equally valid solutions do exist? > > What I believe to be a solution in cases like this, is to sit down with > the stakeholders (preferably in person; a conference or DebConf would be > a perfect opportunity for this): maintainers of said systems, porters > (primarily kFreeBSD & Hurd folk), the security & release teams, and if > possible, upstream developers of the individual init systems too. I'd do > this behind closed doors, initially, because the number of arguments and > the level of noise needs to be controlled, and we've seen how well that > works on a public mailing list. Just to clarify: the intent here is not to lock people up until one emerges, that would be useless and counter productive. I genuinely believe that with the right people having a civil discussion can get results out the door in a reasonable timeframe. They just need some careful herding, is all. And face to face, that can be done - over the internet, nope. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4jb9ez8@galadriel.madhouse-project.org
Re: [all candidates] how to choose Jessie init system
Hi, On 18/03/13 at 13:55 +0100, Stefano Zacchiroli wrote: > Some of the longest -devel thread in recent years have been about > Debian's (default) init system: SysV, SystemD, Upstart, OpenRC, etc. > Despite folklore, I don't think those thread have been (entirely) > trollish, they all hint at a concrete problem: > > How do we make an inherently archive-wide technical decision when > multiple, possibly equally valid solutions do exist? Regarding the default init system decision: There must be compromise in any such issue. My compromise is to ignore anything from lennart. Then, anything from Ubuntu. Once we've done that, we've decided. But sometimes, such archive-wide technical decisions don't involve Lennart or Ubuntu¹, so it's harder to decide. Our goal should be to *make the best decisions*. For that, we need to make sure that there's an healthy discussion. There are several ways someone can contribute to having healthier discussions, and the DPL authority is helpful for them, while not mandatory (I've done what follows on a few occasions myself): - summarize long discussions so that: + people can join the discussion without feeling they have to read everything + the same arguments stop being repeated over and over again - calm down people who get too vocal I find it great that such discussions usually result in a throughout review of the possible solutions by Debian. Often, there's the possibility to limit the impact of the decision, e.g. by providing a default, but also supporting alternatives. When that's possible, that's something that should be explored. It's a good thing for the current alternatives, but also to help future alternatives later. Regarding the decision itself, we often have developers in position to take a decision about the default solution (d-i maintainers, maintainers of important packages that depend on one or the other solutions, etc.) In the last resort, it's also possible to bring the issue to the TC. Also, as I said in https://lists.debian.org/debian-vote/2013/03/msg00132.html, on rare occasions and especially when there's no clear possible decision-maker, we could ask the TC to decide. Lucas PS: [*] In case you are not sure: yes, the first paragraph of my reply was not serious. And mostly motived by: 18:47 lucas: I'll buy you a beer if you post that. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130319203200.gb15...@xanadu.blop.info
Re: [all candidates] how to choose Jessie init system
Stefano Zacchiroli writes: > Some of the longest -devel thread in recent years have been about > Debian's (default) init system: SysV, SystemD, Upstart, OpenRC, etc. > Despite folklore, I don't think those thread have been (entirely) > trollish, they all hint at a concrete problem: (For the record, it's systemd, not SystemD. Sorry!) > How do we make an inherently archive-wide technical decision when > multiple, possibly equally valid solutions do exist? What I believe to be a solution in cases like this, is to sit down with the stakeholders (preferably in person; a conference or DebConf would be a perfect opportunity for this): maintainers of said systems, porters (primarily kFreeBSD & Hurd folk), the security & release teams, and if possible, upstream developers of the individual init systems too. I'd do this behind closed doors, initially, because the number of arguments and the level of noise needs to be controlled, and we've seen how well that works on a public mailing list. We need to estabilish the key requirements (which in this case, will be a though cookie to crack too), and see what compromises the stakeholders are willing to make. The primary role of the DPL in this case would be organisation and mediation, to make sure that those involved understand that compromises will have to be made, or we'll be stuck with sysvinit forever, which is likely not what most of them would want. Also, since there's many people involved, and I would very much like to get upstreams in too, this would not be doable within a single sitting - rather, one discussion where Debian members attempt to come to a few agreements, and another, where upstreams can help us clarify things, or point out any mistakes in our thinking. There will be conflicts of interest, which is another reason I would strongly prefer holding this sprint in person: it is far easier to reason with people in person, far easier to calm the waters when one does not have to fight latency and distance too. Ultimately however, this is a decision that the technical stakeholders will have to make, but the DPL should be there to faciliate the decision, and keep strong opinions from clashing into each other's face. But the task is not nearly done once key requirements are found, not even when compromises are ready to be made - that's just the beginning. A painful transition will have to be planned, the change throughly documented, with strong reasons behind the decision. With all these, the DPL can help, but he'll be at the instructor's wheel at best. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3p3bp6a@galadriel.madhouse-project.org
[all candidates] how to choose Jessie init system
Some of the longest -devel thread in recent years have been about Debian's (default) init system: SysV, SystemD, Upstart, OpenRC, etc. Despite folklore, I don't think those thread have been (entirely) trollish, they all hint at a concrete problem: How do we make an inherently archive-wide technical decision when multiple, possibly equally valid solutions do exist? (I think the latter part, the existence of alternatives, is particularly important here, as we have well-established approaches for other cases. For instance, when one of the alternative is clearly superior, we usually apply some sort of "Debian's Darwinism": we wait for it to be popular enough, we make it increasingly more mandatory in Policy or the Release Team pick it as release goal, we do NMUs, etc.) I'd like to know how the candidates would approach the problem of *helping Debian* making a decision on this matter; decision which we will likely have to make at the beginning of Jessie's release cycle. Personally, I'm not particularly interested in candidates' opinion on the decision per se, but rather on how they think Debian should take similar decisions and which role, if any, the DPL should play in the decision process. Still, I picked a concrete example as it might help focusing our thoughts on how we would like similar important technical decisions to work in the future. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
