Re: Managing Frozen text when the TC Decides Policy
Hello Sam, On Sat 11 May 2019 at 01:24PM -04, Sam Hartman wrote: > I agree that it would generally be unfortunate if we had policy text > that could not be changed by the policy process. I can see rare > situations where it might happen: we might have legal advice requiring > specific text be included in packages under certain circumstances. And > in such a situation it might well be that we'd expect the policy editors > to go back and check with lawyers before changing that frozen text. We actually already have this situation with several bits of text that the Policy Editors don't consider ourselves able to edit without ftpmaster approval. See, for example, #904729 and #912581. > I think the policy editors could handle this by deciding amongst > themselves how they want to interact with the TC and then writing a note > to the TC along the following lines adapted based on what the policy > editors think the write answer is: Thank you for taking the time to think about this carefully, but I would like to suggest that we set is aside until and unless we have a concrete situation in which the Policy Editors feel that we can't make a change to the Policy Manual because of a particular T.C. decision. It's very complicated and time-consuming to discuss in the abstract, and it has not actually been a problem in at least the last two to three years. -- Sean Whitton signature.asc Description: PGP signature
Re: Thinking about Delegating Decisions about Policy
Hello Sam, On Fri 10 May 2019 at 03:57PM -04, Sam Hartman wrote: > What are people's thoughts about this? > > Will this approach work for the TC and policy editors? I think that the concrete suggestion you're making is that when a question that comes before the T.C. is something that could be solved by patching the Policy Manual, the T.C. should respond to the question by opening a bug against the Policy Manual, and suspending the T.C. bug until it becomes clear whether or not that debian-policy bug is going to reach consensus? -- Sean Whitton signature.asc Description: PGP signature
Re: Thinking about Delegating Decisions about Policy
Hello Ian, On Mon 13 May 2019 at 02:50PM +01, Ian Jackson wrote: >> we delegated managing the process to the policy editors, but not the >> actual policy decisions. They make consensus calls. They use their >> judgment in a lot of ways. > > That is a decision *of* the policy editors. When the constitution was > first adopted, and for some time afterwards, the policy editors > themselves made judgement calls about merit, rather than simply trying > to assess consensus. > > [...] > >> But at least under the current process, the policy editors cannot just >> use their personal judgment to decide what policy is absent a consensus. > > The policy editors collectively could decide to change the process. > The process is a creation of the policy editors, not of the DPL nor of > the rest of the project. Firstly, let me confirm that I share this understanding of what powers the Policy Editors formally possess. I actually wrote it into Policy in a recent release, section 1.3.2. (I am also responsible for moving the Policy Changes Process into the Policy Manual itself as an appendix. It was not my main motivation at the time, IIRC, but in fact the change has made the status of the Policy Changes Process a bit clearer than when it was just a wiki page.) > IMO the biggest problem is the principle that policy should always > follow practice rather than lead it - even if the project has rough > consensus about the direction. I really don't think that is best. > > There is a missed opportunity here. The policy editors and the policy > list have a good reputation and a lot of legitimacy. That comes from > their practice of caution, of consulting widely, and seeking rough > consensus. > > I wouldn't want to change that dramatically but a small change from > the policy editors would go a long way. For example, to be willing to > countenance making recommendations which have rough consensus, and > seem to the editors like a good way forward, but which are followed > only occasionally or patchily. > > That would not involve goring anyone's ox, so it would not undermine > the policy team's political capital. Obviously any change might be > opposed by someone but I doubt such a change in policy practice would > meet much opposition. The idea that Policy should always lag behind practice is something that I find very difficult to assess. If you are thinking of Debian as a large number of people furiously innovating at the borders and exchanging ideas with each other in the form of uploads, then it makes complete sense. On the other hand, to the extent that we're a group of people struggling to communicate best practices to large numbers of people working largely independently on mostly maintainance work, it seems a lot less helpful. (Debian is, of course, both of these things.) My current strategy, when - it seems like something is important and should be changed, but - it has not yet been implemented in the archive, or - in some other sense lacks a clear consensus, is to refer the case to the T.C. I think your suggestion is that in at least some such cases we should lower our standards for what is required for a clear consensus? If so, am I right in thinking this would not actually require any changes to the Policy Changes Process? > Additionally I think the formal proposer/seconder scheme can be > awkward. Again I think the policy editors adopted it because they > didn't want to be in the line of fire when difficult decisions are > being made, and perhaps because they didn't want to try to become > experts in everything. But it means that uncontroversial changes can > languish. Do you (or anyone else) have any concrete ideas for simplifying the proposer/seconder scheme, without significantly reducing the oversight on changes, even uncontroversial ones? -- Sean Whitton signature.asc Description: PGP signature
Bug#923450: tech-ctte: requirements for being pre-dependency of bin:init
On Thu, 28 Feb 2019 at 12:06:15 +, Dmitry Bogatov wrote: > currently, inclusion of new init system into Debian requires inclusion into > pre-dependency of bin:init package, which is unsatisfactory. > > As can be followed in #838480, current practice puts maintainer of any > new init system to be included into Debian at disadvantage, essentially > granting maintainer of bin:init (which happens to be `systemd' team now) > veto right. According to Constitution 3.1, individual developer poses > power of descision making only with regard their /own/ work. > > Hereby, I ask TCCE to provide requirements init system must satisfy that > /warrants/ inclusion into pre-dependency of essential bin:init. > Alternatively, I ask to consider introducion of virtual package > 'init-system'. We discussed this at last month's technical committee meeting (sorry for the delay in replying - I've been busy IRL, and so was the person previously asked to reply). Committee consensus --- Yes, we agree that the maintainers of the init-system-helpers package (which builds the init binary) have a gatekeeper role for making init systems as straightforward to install to /sbin/init as e.g. sysvinit is. We don't consider this to be a problem. They seem to be applying due scrutiny and care to this process, based in part on experience that they gained during systemd's time as an unsupported/non-default init system. We would recommend that the init-system-helpers maintainers should document their requirements for being an alternative pre-dependency of init, for instance in init's README.Debian. I'll mention some possible criteria further down this mail, but those are not part of the committee consensus (and detailed design work is, constitutionally, not a function of the technical committee, although some of us might be able to provide useful suggestions in our personal/non-TC roles, and I have tried to do so). It is entirely possible to include init systems in Debian without being pre-dependencies of init: for instance, at the time systemd was made available as a non-default init during the wheezy release cycle, the recommended mechanism to use it was to boot with init=/bin/systemd. People who are interested in trying new init systems that are not pre-dependencies of init can do the same, and we would recommend structuring runit packaging to make this possible if it isn't already. (For example, systemd was available and worked well in wheezy, but was most straightforward to test by using init=/bin/systemd; the systemd-sysv package, which makes systemd provide /sbin/init, couldn't be installed without applying force until part way through the jessie release cycle.) Another way to use an init system that is not a pre-dependency of init is to override the Important flag and remove init. I think we have a consensus that we consider this to be a feature, not a bug: it provides an indication that this particular non-default init system is unlikely to be suitable for people who do not know for sure that they want it. We do not consider an init-system virtual package to be a suitable solution here. My personal suggestions --- As a general operating principle, I think adding a new init system to the pre-dependencies of init should only be done when the init system is definitely entirely ready for general use, and has already been tested on a variety of systems by multiple people (by alternative mechanisms like booting with init=/sbin/my-init or overriding the Important flag to uninstall the init package); so modifying init should be the last step in enabling a new init system. I don't think there should be a presumption that Debian should consider every init system that has been packaged to be equally important or equally strongly supported, and if it isn't obvious that a new init system is ready for wide use, then it probably isn't. Some criteria that the init-system-helpers maintainers might like to consider, which I believe are all satisfied by systemd and sysv-rc, and were satisfied by upstart before it was removed from the archive: * If the init system is booted in the most obvious way on a simple TUI system (similar to a default Debian install with Priority: standard packages), it should start at least one console getty on a VT for interactive login, without the sysadmin needing to set this up manually. * It should be possible to configure the init system to provide a getty on a serial console, for testability on headless servers and VMs, and it should be documented how to do this. (systemd makes this very convenient, by starting a getty on the kernel console by default, and I would encourage this approach. sysvinit is less convenient here, but does at least have a relatively well-known way to enable a getty on a serial console.) * If the init system is booted in the most obvious way on a simple GUI system, it should be possible to start an X11 display manager and log
