On 20/10/14 at 08:06 +0900, Charles Plessy wrote: > Le Sun, Oct 19, 2014 at 05:01:02PM +0200, Lucas Nussbaum a écrit : > > > > > > --------------------------------------------------------------------------- > > > > > > The Debian project asks its members to be considerate when proposing > > > General > > > Resolutions, as the GR process may be disruptive regardless of the > > > outcome of > > > the vote. > > > > > > Regarding the subject of this ballot, the Project affirms that the > > > question > > > has already been resolved and thus does not require a General Resolution. > > > > > > --------------------------------------------------------------------------- > > > > I think that it would be very helpful to describe how "the question has > > already been resolved". My understanding is that the various proposals > > add policy on something that isn't currently covered by the Debian Policy > > or by TC decisions. > > > > Alternatively, your resolution could state that the current de-facto > > policy of supporting both systemd and sysvinit (sometimes through > > systemd-shim) should be kept for Debian jessie, and that deciding > > on policy beyond jessie is premature at this point. > > Hi Lucas, > > being more precise would somehow defeat the point of stating that no GR is > needed, because the way the solution would be expressed, with its > imperfections, would then become binding. > > This said, let me clarify my understanding of the current situation. > > - Pepole running GNOME and desktops needing features not found in > other init systems will be migrated to systemd during update.
I don't think that's correct. What to do during upgrades is still being discussed by the TC in #765803, and none of the amendments in the current GR discuss this. Also, thanks to the work on systemd-shim, it should be possible to upgrade from wheezy+GNOME with sysvinit to jessie+GNOME with sysvinit and systemd-shim. (I just tried, and the dist-upgrade currently fails to upgrade gnome, but it seems unrelated to init systems issues) > - Whether other people will be migrated or invited to migrate is in > the hands of the release team, who decides which packages are > part of Jessie or not. Well, it's true that the release team can control which packages are fit for integration into testing. But I don't think that the release team wants to use (abuse?) that to define our technical policy on init systems... > The techincal commttee has already given the general direction: we change the > default init system. In my opinion, this general direction is how the > “question” is resolved. Current decisions on which package depend on what, > etc, stem from that decision. As of today I do not think that we need the > technical comittee, the Policy or a GR to further constrain the work of the > release team. Replacing the init system is a major change, and obviously some > people who used expert skills to set up their system may need their expertise > to upgrade it. This, also, is a logical consequence of the TC's decision, and > I trust the various package maintainers that they are doing their best to make > the transition as easy as possible. TTBOMK, the various TC decisions related to this matter are: #727708 - https://lists.debian.org/debian-devel-announce/2014/02/msg00005.html default init system on Linux is systemd https://lists.debian.org/878usv4ruj....@rover.gag.com no decision on whether software may require specific init systems https://lists.debian.org/debian-devel-announce/2014/08/msg00001.html (which I understand as technical advice, and Russ said the same thing in <87fvei8t2z....@hope.eyrie.org>) For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. I don't think that this fully covers all the questions raised in the various amendments to this GR. I would very much prefer if your proposal said something such as: Regarding the subject of this ballot, the Project affirms that most of the questions have already been resolved. Resolving the remaining questions via a General Resolution is premature at this time. (I would vote the above first -- I'm unsure about your proposal) Lucas
signature.asc
Description: Digital signature
