From: Don Armstrong Date: Wed, 24 Jun 2015 16:38:04 +0000 (-0700) Subject: move old issues to the resolved_issues directory X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=91838e59e98b12ec672fa02cceb7a957b15f3bd0;p=debian-ctte.git move old issues to the resolved_issues directory --- diff --git a/681419_free_non_free_dependencies/681419_free_non_free_dependencies.org b/681419_free_non_free_dependencies/681419_free_non_free_dependencies.org deleted file mode 100644 index 2200049..0000000 --- a/681419_free_non_free_dependencies/681419_free_non_free_dependencies.org +++ /dev/null @@ -1,27 +0,0 @@ -* Issue http://bugs.debian.org/681419 -** May packages in main have a Depends: foo | foo-nonfree -* Possible Solutions -** Yes - + Possibility of automatically pulling in non-free during some - dependency resolution -** Yes, with caveats - + Under no circumstances should non-free be pulled in automatically -*** Automatic: avoid in Release file - + http://lists.debian.org/msgid-search/20120717083004.GB21400@frosties -*** Only virtual packages -** No - + Lots of packages will be insta-buggy -* Open Questions -** How many total dependencies are there? (We're only interested in Depends or Recommends for this purpose, not Suggests.) -*** 79 -** Are all of those dependencies alternative dependencies of the form: Depends: foo | foo-nonfree or are there other cases? -*** Yes, save for two bugs -** Are any of these dependencies versioned? -*** No -** What do packages already in the archive do? -*** Already some alternative Depends: and Recommends: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681419#100 -** Do any packages pull in non-free automatically already? -*** Apparently, no http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681419#100 -** What about suggests -* Involved Parties -** debian-policy@lists.debian.org diff --git a/681419_free_non_free_dependencies/cjwatson_draft.txt b/681419_free_non_free_dependencies/cjwatson_draft.txt deleted file mode 100644 index f07b7d1..0000000 --- a/681419_free_non_free_dependencies/cjwatson_draft.txt +++ /dev/null @@ -1,97 +0,0 @@ - Whereas: - - 1. The Debian Policy Manual states (§2.2.1) that packages in main - "must not require or recommend a package outside of main for - compilation or execution". Both "Depends: package-in-non-free" and - "Recommends: package-in-non-free" clearly violate this requirement. - The Technical Committee has been asked to determine whether a - dependency of the form "package-in-main | package-in-non-free" - complies with this policy requirement, or whether virtual packages - must instead be used to avoid mentioning the non-free alternative. - - 2. Both options have the following effects in common, meeting the - standard that main should be functional and useful while being - self-contained: - - (a) Package managers configured to consider only main will install - package-in-main. - - (b) Package managers configured to consider both main and non-free - will prefer to install package-in-main, but may install - package-in-non-free instead if so instructed, or if - package-in-main is uninstallable. - - (c) If package-in-non-free is already installed, package managers - will proceed without installing package-in-main. - - 3. The significant difference between these two options is that the - former makes the non-free alternative visible to everyone who - examines the dependency relationship, while the latter does not. - -A 4. Merely mentioning that a non-free alternative exists does not -A constitute a recommendation of that alternative. For example, many -A free software packages state quite reasonably that they can be -A compiled and executed on non-free platforms. -A -A 5. Furthermore, virtual packages are often a clumsy way to express -A these kinds of alternatives. If a package happens to require any -A of several implementations of a facility that have a certain -A option, then it can either depend on suitable alternatives -A directly, or its maintainer can first attempt to have fine-grained -A virtual packages added to each of the packages they wish to permit. -A In some cases this may be appropriate, but it can easily turn into -A quite a heavyweight approach. -A -A Therefore: -A -A 6. The Technical Committee resolves that alternative dependencies of -A the form "Depends: package-in-main | package-in-non-free" are -A permissible in main, and do not constitute a violation of the -A policy clause cited in point 1. -A -A 7. We nevertheless recommend that packages in main consider carefully -A whether this might cause the inadvertent installation of non-free -A packages due to conflicts, especially those with usage -A restrictions. - -B 4. Listing a package explicitly in a Recommends field clearly states -B that we are recommending it, even if the package appears only as -B a secondary alternative. Official statements to the contrary are -B ineffective at preventing readers from getting the impression -B that packages mentioned in "Recommends" are being recommended. -B -B 5. One of the main goals of the Debian Project is to promote -B software freedom. Promoting software freedom includes avoiding -B promoting non-free software, at the very least when it's -B straightforward to do so. -B -B 6. The alternative, of using a neutrally-named virtual package, is -B only slightly inconvenient. Virtual packages are a suitable -B existing mechanism for packages to declare the set of abstract -B features they provide, and allow packages in main to depend on -B such abstract features without needing to name every (free or -B non-free) alternative. They should nevertheless name at least one -B free preferred alternative, so that the package management system -B has appropriate defaults. -B -B 7. There are not very many dependencies which need to be fixed. -B In any case, changing the policy (without making this a release -B critical bug) doesn't constitute a demand that the existing -B maintainers do this work. However, it is needed to ensure that -B those who do want to do the work can get their changes accepted. -B -B Therefore: -B -B 8. The Technical Committee resolves that alternative dependencies of -B the form "Depends: package-in-main | package-in-non-free" -B constitute a non-release-critical violation of the policy -B clause cited in point 1. -B -B 9. When it is necessary to provide a reference in a Depends or -B Recommends from main to non-free, this should be done via a -B neutrally named virtual package. Packages depending on such a -B virtual package should specify a real package in main as the first -B alternative, e.g. "Depends: package-in-main | virtual-interface". -B -B 10. The Technical Committee requests that the policy editors make -B an appropriate clarification to the policy documents. diff --git a/681419_free_non_free_dependencies/decision b/681419_free_non_free_dependencies/decision deleted file mode 100644 index 2f8ecce..0000000 --- a/681419_free_non_free_dependencies/decision +++ /dev/null @@ -1,77 +0,0 @@ -===== TITLE - -Alternate Dependencies on non-free packages in main - -===== WEB SUMMARY - -The committee resolves that alternatiave dependencies on non-free -packages are permisible in main. - -===== EMAIL INTRO - -The technical committe was asked in #681419 by the policy maintainers -to determine as a matter of technical whether alternative dependencies -on non-free packages were acceptable in main. - -===== EMAIL EPILOGUE - -The committee would like to thank everyone who participated in the -discussion of #681419. - -===== DECISION - -Whereas: - -1. The Debian Policy Manual states (§2.2.1) that packages in main - "must not require or recommend a package outside of main for - compilation or execution". Both "Depends: package-in-non-free" and - "Recommends: package-in-non-free" clearly violate this requirement. - The Technical Committee has been asked to determine whether a - dependency of the form "package-in-main | package-in-non-free" - complies with this policy requirement, or whether virtual packages - must instead be used to avoid mentioning the non-free alternative. - -2. Both options have the following effects in common, meeting the - standard that main should be functional and useful while being - self-contained: - - (a) Package managers configured to consider only main will install - package-in-main. - - (b) Package managers configured to consider both main and non-free - will prefer to install package-in-main, but may install - package-in-non-free instead if so instructed, or if - package-in-main is uninstallable. - - (c) If package-in-non-free is already installed, package managers - will proceed without installing package-in-main. - -3. The significant difference between these two options is that the - former makes the non-free alternative visible to everyone who - examines the dependency relationship, while the latter does not. - -4. Merely mentioning that a non-free alternative exists does not - constitute a recommendation of that alternative. For example, many - free software packages state quite reasonably that they can be - compiled and executed on non-free platforms. - -5. Furthermore, virtual packages are often a clumsy way to express - these kinds of alternatives. If a package happens to require any - of several implementations of a facility that have a certain - option, then it can either depend on suitable alternatives - directly, or its maintainer can first attempt to have fine-grained - virtual packages added to each of the packages they wish to permit. - In some cases this may be appropriate, but it can easily turn into - quite a heavyweight approach. - -Therefore: - -6. The Technical Committee resolves that alternative dependencies of - the form "Depends: package-in-main | package-in-non-free" are - permissible in main, and do not constitute a violation of the - policy clause cited in point 1. - -7. We nevertheless recommend that packages in main consider carefully - whether this might cause the inadvertent installation of non-free - packages due to conflicts, especially those with usage - restrictions. \ No newline at end of file diff --git a/717076_libjpeg/cjwatson_draft.txt b/717076_libjpeg/cjwatson_draft.txt deleted file mode 100644 index 350dd71..0000000 --- a/717076_libjpeg/cjwatson_draft.txt +++ /dev/null @@ -1,67 +0,0 @@ - Whereas: - - 1. There is a dispute between Developers about whether libjpeg8/9 or - libjpeg-turbo should be the default libjpeg implementation in - Debian. The release team does not want to have more than one - libjpeg implementation. - - 2. The Debian libjpeg8 maintainer does not see libjpeg-turbo as a - suitable replacement, and notes that it does not implement the - full libjpeg8/9 ABI. - - 3. libjpeg8 adds new features to the JPEG image format. These have - however been rejected from the ISO standard, and their - contributions to image quality and compression appear to be widely - disputed. - - 4. libjpeg-turbo is reported to have significantly better performance - than libjpeg, and to be API/ABI-compatible with libjpeg6b. - - 5. libjpeg-turbo is in use by several other distributions (at least - Fedora, Gentoo, openSUSE, Ubuntu) and browser projects (WebKit, - Blink, Gecko). - - 6. The former organiser of the IJG advised Fedora of his opinion that - libjpeg8 was a "dead end" due to fragmentation. - - 7. The libjpeg-turbo packages in Debian are not yet in a state where - they could be a drop-in replacement for libjpeg8. However, - similar work has been done in Ubuntu and could be adopted. - - 8. In general it does not appear that other Debian packages require - the libjpeg8 API. The sole exception appears to be a "decode from - memory buffer" interface (jpeg_mem_src/jpeg_mem_dest), which is - implemented by libjpeg-turbo unless configured - --without-mem-srcdst. - - 9. While libjpeg-turbo can be configured with support for much of the - newer interfaces in libjpeg8, it does not support the SmartScale - API. However, images with this extension may have - interoperability problems. Those developers advocating - libjpeg-turbo generally suggest disabling the libjpeg7/libjpeg8 - APIs there. - - Therefore: - -A (3:1 majority required) -A -A 10. The Technical Committee resolves that libjpeg-turbo should become -A the libjpeg implementation in Debian, using its power under 6.1(2) -A to decide on technical matters of overlapping jurisdiction. -A -A 11. The prospective libjpeg-turbo maintainer should propose an appropriate -A transition plan for this change, and, after a reasonable period for -A comment, prepare tested packages for upload. -A -A 12. Implementing this change will require removing "Provides: -A libjpeg-dev" from libjpeg8. The libjpeg8 maintainer has made his -A preference clear that libjpeg8 should remain as the default -A libjpeg. Under 6.1(4), we overrule this decision and require that -A this Provides be removed in accordance with the libjpeg-turbo -A transition plan. - -B 10. The Technical Committee resolves that libjpeg8/9 should remain -B the libjpeg implementation in Debian, using its power under 6.1(2) -B to decide on technical matters of overlapping jurisdiction. - -(Option A requires a 3:1 majority.) diff --git a/717076_libjpeg/decision b/717076_libjpeg/decision deleted file mode 100644 index 1aeaa6d..0000000 --- a/717076_libjpeg/decision +++ /dev/null @@ -1,86 +0,0 @@ -===== TITLE - -Default libjpeg implementation in Debian - -===== WEB SUMMARY - -The committee decided that the default libjpeg implementation should -be libjpeg-turbo. - -===== EMAIL INTRO - -The technical committee was asked in #717076 to decide whether -libjpeg8 or libjpeg-turbo would be the default libjpeg implementation. -The decision is below: - -===== EMAIL EPILOGUE - - -===== DECISION - -Whereas: - - 1. There is a dispute between Developers about whether libjpeg8/9 or - libjpeg-turbo should be the default libjpeg implementation in - Debian. The release team does not want to have more than one - libjpeg implementation. - - 2. The Debian libjpeg8 maintainer does not see libjpeg-turbo as a - suitable replacement, and notes that it does not implement the - full libjpeg8/9 ABI. - - 3. libjpeg8 adds new features to the JPEG image format. These have - however been rejected from the ISO standard, and their - contributions to image quality and compression appear to be widely - disputed. - - 4. libjpeg-turbo is reported to have significantly better performance - than libjpeg, and to be API/ABI-compatible with libjpeg6b. - - 5. libjpeg-turbo is in use by several other distributions (at least - Fedora, Gentoo, openSUSE, Ubuntu) and browser projects (WebKit, - Blink, Gecko). - - 6. The former organiser of the IJG advised Fedora of his opinion that - libjpeg8 was a "dead end" due to fragmentation. - - 7. The libjpeg-turbo packages in Debian are not yet in a state where - they could be a drop-in replacement for libjpeg8. However, - similar work has been done in Ubuntu and could be adopted. - - 8. In general it does not appear that other Debian packages require - the libjpeg8 API. The sole exception appears to be a "decode from - memory buffer" interface (jpeg_mem_src/jpeg_mem_dest), which is - implemented by libjpeg-turbo unless configured - --without-mem-srcdst. - - 9. While libjpeg-turbo can be configured with support for much of the - newer interfaces in libjpeg8, it does not support the SmartScale - API. However, images with this extension may have - interoperability problems. Those developers advocating - libjpeg-turbo generally suggest disabling the libjpeg7/libjpeg8 - APIs there. - -Therefore: - -10. The Technical Committee resolves that libjpeg-turbo should - become the libjpeg implementation in Debian, using its power - under 6.1(2) to decide on technical matters of overlapping - jurisdiction. - -11. The prospective libjpeg-turbo maintainer should propose an appropriate - transition plan for this change, and, after a reasonable period for - comment, prepare tested packages for upload. The transition - plan should state the timescales for the relevant changes. - -12. Implementing the decision in 10 above will require removing - "Provides: libjpeg-dev" from libjpeg8, since such a virtual - package must be provided by only one real package at a time. - Therefore the Provides should be removed from the libjpeg8 - package - in accordance with the transition plan - - notwithstanding the libjpeg8 maintainer's preference that - libjpeg8 should remain as the default libjpeg. This change - should be made by the libjpeg8 maintainer; if the change is not - made within a reasonable time it should be done in an NMU by the - libjpeg-turbo maintainer. - diff --git a/727708_initsystem/coupling-iwj-col-iwj.txt b/727708_initsystem/coupling-iwj-col-iwj.txt deleted file mode 100644 index 2464e9a..0000000 --- a/727708_initsystem/coupling-iwj-col-iwj.txt +++ /dev/null @@ -1,52 +0,0 @@ -L Software may not depend on a specific init system -==================================================== - - Rationale - - The default init system decision is limited to selecting a default - initsystem for jessie. We expect that Debian will continue to - support multiple init systems for the foreseeable future; we - continue to welcome contributions of support for all init systems. - - Rubric - - Therefore, for jessie and later releases, we exercise our power to - set technical policy (Constitution 6.1.1): - - Loose coupling - - In general, software may not require a specific init system to be - pid 1. The exceptions to this are as follows: - - * alternative init system implementations - * special-use packages such as managers for init systems - * cooperating groups of packages intended for use with specific init - systems - - provided that these are not themselves required by other software - whose main purpose is not the operation of a specific init system. - - Degraded operation with some init systems is tolerable, so long as - the degradation is no worse than what the Debian project would - consider a tolerable (non-RC) bug even if it were affecting all - users. So the lack of support for a particular init system does not - excuse a bug nor reduce its severity; but conversely, nor is a bug - more serious simply because it is an incompatibility of some software - with some init system(s). - - Maintainers are encouraged to accept technically sound patches - to enable improved interoperation with various init systems. - - GR rider - - If the project passes (before the release of jessie) by a General - Resolution, a "position statement about issues of the day", on the - subject of init systems, the views expressed in that position - statement entirely replace the substance of this TC resolution; the - TC hereby adopts any such position statement as its own decision. - - Such a position statement could, for example, use these words: - - The Project requests (as a position statement under s4.1.5 of the - Constitution) that the TC reconsider, and requests that the TC - would instead decide as follows: diff --git a/727708_initsystem/coupling-keithp.txt b/727708_initsystem/coupling-keithp.txt deleted file mode 100644 index 5f27eb3..0000000 --- a/727708_initsystem/coupling-keithp.txt +++ /dev/null @@ -1,5 +0,0 @@ -N No TC resolution on this question at this time -================================================= - - The TC chooses to not pass a resolution at the current time - about whether software may require specific init systems. diff --git a/727708_initsystem/coupling-russ-aba.txt b/727708_initsystem/coupling-russ-aba.txt deleted file mode 100644 index 22f5b1f..0000000 --- a/727708_initsystem/coupling-russ-aba.txt +++ /dev/null @@ -1,38 +0,0 @@ -A Advice: sysvinit compatibility in jessie and multiple init support -===================================================================== - - The following is technical advice offered to the project by the - Technical Committee under section 6.1.5 of the constitution. It does - not constitute an override of maintainer decisions past or future. - - Software should support as many architectures as reasonably possible, - and it should normally support the default init system on all - architectures for which it is built. There are some exceptional cases - where lack of support for the default init system may be appropriate, - such as alternative init system implementations, special-use packages - such as managers for non-default init systems, and cooperating - groups of packages intended for use with non-default init systems. - However, package maintainers should be aware that a requirement for a - non-default init system will mean the software will be unusable for - most Debian users and should normally be avoided. - - Package maintainers are strongly encouraged to merge any contributions - for support of any init system, and to add that support themselves if - they're willing and capable of doing so. In particular, package - maintainers should put a high priority on merging changes to support - any init system which is the default on one of Debian's non-Linux - ports. - - For the jessie release, all software that currently supports being run - under sysvinit should continue to support sysvinit unless there is no - technically feasible way to do so. Reasonable changes to preserve - or improve sysvinit support should be accepted through the jessie - release. There may be some loss of functionality under sysvinit if - that loss is considered acceptable by the package maintainer and - the package is still basically functional, but Debian's standard - requirement to support smooth upgrades from wheezy to jessie still - applies, even when the system is booted with sysvinit. - - The Technical Committee offers no advice at this time on sysvinit - support beyond the jessie release. There are too many variables at - this point to know what the correct course of action will be. diff --git a/727708_initsystem/coupling_votes.txt b/727708_initsystem/coupling_votes.txt deleted file mode 100644 index 1e06ed3..0000000 --- a/727708_initsystem/coupling_votes.txt +++ /dev/null @@ -1,11 +0,0 @@ -# this file is in a format that -# http://www.chiark.greenend.org.uk/ucgi/~ian/git/appendix-a6.git/ -# understands -ian :: L, N, A, FD -russ :: N, A, L, FD -don :: A , N , L , FD -colin :: L , N , A , FD -bdale :: N, A, FD, L -keith :: N, A, FD, L -andreas :: L, A, N, FD -steve :: L, A, N, FD diff --git a/727708_initsystem/decision b/727708_initsystem/decision deleted file mode 100644 index dc8c402..0000000 --- a/727708_initsystem/decision +++ /dev/null @@ -1,31 +0,0 @@ -===== TITLE - -Default init system for Debian - -===== WEB SUMMARY - -The committee decided that the default init system for Linux -architectures in jessie should be systemd. - -===== EMAIL INTRO - -The technical committee was asked in #727708 to decide which init -system would be the default init system for Debian. The decision is -below: - -===== EMAIL EPILOGUE - -Additional discussions regarding the technical policy necessary for -implementing this decision are anticipated and will be carried out via -the normal technical policy procedure. - -===== DECISION - -We exercise our power to decide in cases of overlapping jurisdiction -(6.1.2) by asserting that the default init system for Linux -architectures in jessie should be systemd. - -Should the project pass a General Resolution before the release of -"jessie" asserting a "position statement about issues of the day" on -init systems, that position replaces the outcome of this vote and is -adopted by the Technical Committee as its own decision. diff --git a/746578_libpam-systemd_dependencies/decision b/746578_libpam-systemd_dependencies/decision deleted file mode 100644 index 92799ff..0000000 --- a/746578_libpam-systemd_dependencies/decision +++ /dev/null @@ -1,64 +0,0 @@ -===== TITLE - -libpam-systemd to switch alternate dependency ordering - -===== WEB SUMMARY - -The committee decided that systemd-shim should be the first listed -alternative dependency of libpam-systemd instead of systemd-sysv. - -===== EMAIL INTRO - -The technical committe was asked in #746578 to override the ordering -of the alternative dependencies on systemd-sysv and systemd-shim to -prefer the installation of systemd-shim in cases where sysvinit-core -was already installed. - -===== EMAIL EPILOGUE - -The committee would like to thank everyone who participated in the -discussion of #746578, especially Josh Triplett, Serge Hallyn, Sam -Hartman, Cameron Norman, and Michael Biebl. - -===== DECISION - -Rationale (Constitution 6.1(5)): - -1. Currently libpam-systemd (which is pulled in by quite a few - dependency chains) Depends on `systemd-sysv | systemd-shim (>= 8-2)'. - -2. The effect of this is that installing some packages which depend - (directly or indirectly) on libpam-systemd can cause a user's init - system to be switched to systemd, even on systems where a user has - deliberately chosen not to use the default init system, and even - when the switch is unnecessary. - -3. Swappping the order of these dependencies would avoid that and has - no harmful effect: - -4. In particular, on systems that already have systemd-sysv installed, - libpam-systemd will still not pull in systemd-shim, thus minimizing - the risk of breakage on systemd systems. However, on systems that - intentionally do not have systemd-sysv installed, the installation - of libpam-systemd will then prefer to pull in systemd-shim and keep - the installed init system rather than switching to systemd-sysv. - -Decision (Constitution 6.1(4)): - -5. We therefore overrule the decision of the maintainer of - libpam-systemd binary package. The Depends entry - systemd-sysv | systemd-shim (>= 8-2) - should be replaced by - systemd-shim (>= 8-2) | systemd-sysv - -6. For the avoidance of doubt, we do not intend to set this specific - syntax in stone. For example, if in future libpam-systemd needs to - depend on a later systemd-shim, or needs a versioned rather than - unversioned dependency on systemd-sysv, that is fine and would not - contradict our decision. - -Release (Constitution 6.1(5)): - -7. Our advice is that this change should be in jessie. If necessary, - this view should be conveyed to the Release Team, after the change - is in unstable, by filing an unblock request in the usual way. diff --git a/746578_libpam-systemd_dependencies/draft.txt b/746578_libpam-systemd_dependencies/draft.txt deleted file mode 100644 index f066fef..0000000 --- a/746578_libpam-systemd_dependencies/draft.txt +++ /dev/null @@ -1,40 +0,0 @@ -Rationale (Constitution 6.1(5)): - -1. Currently libpam-systemd (which is pulled in by quite a few - dependency chains) Depends on `systemd-sysv | systemd-shim (>= 8-2)'. - -2. The effect of this is that installing some packages which depend - (directly or indirectly) on libpam-systemd can cause a user's init - system to be switched to systemd, even on systems where a user has - deliberately chosen not to use the default init system, and even - when the switch is unnecessary. - -3. Swappping the order of these dependencies would avoid that and has - no harmful effect: - -4. In particular, on systems that already have systemd-sysv installed, - libpam-systemd will still not pull in systemd-shim, thus minimizing - the risk of breakage on systemd systems. However, on systems that - intentionally do not have systemd-sysv installed, the installation - of libpam-systemd will then prefer to pull in systemd-shim and keep - the installed init system rather than switching to systemd-sysv. - -Decision (Constitution 6.1(4)): - -5. We therefore overrule the decision of the maintainer of - libpam-systemd binary package. The Depends entry - systemd-sysv | systemd-shim (>= 8-2) - should be replaced by - systemd-shim (>= 8-2) | systemd-sysv - -6. For the avoidance of doubt, we do not intend to set this specific - syntax in stone. For example, if in future libpam-systemd needs to - depend on a later systemd-shim, or needs a versioned rather than - unversioned dependency on systemd-sysv, that is fine and would not - contradict our decision. - -Release (Constitution 6.1(5)): - -7. Our advice is that this change should be in jessie. If necessary, - this view should be conveyed to the Release Team, after the change - is in unstable, by filing an unblock request in the usual way. diff --git a/746715_initsystemfallout/decision b/746715_initsystemfallout/decision deleted file mode 100644 index 02946bc..0000000 --- a/746715_initsystemfallout/decision +++ /dev/null @@ -1,28 +0,0 @@ -===== TITLE - -Continuing support for multiple init systems - -===== WEB SUMMARY - -The technical committee expects maintainers to continue to support the -multiple available init systems. - -===== EMAIL INTRO - -The technical committe was asked in #746715 to address the removal of -support for upstart in a package. - -===== EMAIL EPILOGUE - - -===== DECISION - -The issue of init system support recently came to the Technical -Committee's attention again.[1] - -For the record, the TC expects maintainers to continue to support -the multiple available init systems in Debian. That includes -merging reasonable contributions, and not reverting existing -support without a compelling reason. - -[1] See #746715 for background. diff --git a/746715_initsystemfallout/draft.txt b/746715_initsystemfallout/draft.txt deleted file mode 100644 index bb0ac88..0000000 --- a/746715_initsystemfallout/draft.txt +++ /dev/null @@ -1,9 +0,0 @@ - The issue of init system support recently came to the Technical - Committee's attention again.[1] - - For the record, the TC expects maintainers to continue to support - the multiple available init systems in Debian. That includes - merging reasonable contributions, and not reverting existing - support without a compelling reason. - - [1] See #746715 for background. diff --git a/750135_aptitude/decision b/750135_aptitude/decision deleted file mode 100644 index f450905..0000000 --- a/750135_aptitude/decision +++ /dev/null @@ -1,58 +0,0 @@ -===== TITLE - -Aptitude Project Maintainer - -===== WEB SUMMARY - -The technical committee encorages Christian Perrier to implement his -proposal for maintenance of the Aptitude project. - -===== EMAIL INTRO - -The technical committee was asked in #750135 to address who would -maintain the Aptitude project. - -===== EMAIL EPILOGUE - -===== DECISION - -Background/Rationale: - -1. In #750135, the Technical Committee was asked by Manuel Fernandez - Montecelo who should be the maintainer of the Aptitude project. - - Manuel Fernandez Montecelo had been actively committing until his - commit access was removed by Daniel Hartwig. - - Manuel Fernandez Montecelo and Daniel Hartwig took over development - of Aptitude in 2011 with the support of Christian Perrier, an admin - for the Aptitude alioth project. - - There was friction between Manuel Fernandez Montecelo and Daniel - Hartwig, which eventually resulted in Manuel Fernandez Montecelo's - commit access being revoked by Daniel Hartwig. - - Since then, Daniel Hartwig has become inactive, and did not comment - on the issue when requested by the Technical Committee. - -2. During the discussion of this issue, Christian Perrier proposed - that he and Axel Beckert could watch the social aspects of Aptitude - development and restore Manuel Fernandez Montecelo's commit access. - - Christian still has administrative rights and believes he has the - technical power to implement his proposal, but requested the advice - of the technical committee before doing so. - -Using the power of the technical committee to provide advice (§6.1.5): - -1. The Technical Committee agrees that Christian has the power to - implement his proposal and encourages him to do so. - -2. We hope that Christian and Axel will work to manage the social - aspects of the Aptitude project, working to recruit new developers, - building a stronger Aptitude development community, and - establishing policies and procedures that promote a collaborative - team. - -3. We thank Manuel Fernandez Montecelo for bringing this matter to our - attention and apologize for our delay in resolving this matter. diff --git a/750135_aptitude/draft b/750135_aptitude/draft deleted file mode 100644 index 07dfcfb..0000000 --- a/750135_aptitude/draft +++ /dev/null @@ -1,40 +0,0 @@ -Background/Rationale: - -1. In #750135, the Technical Committee was asked by Manuel Fernandez - Montecelo who should be the maintainer of the Aptitude project. - - Manuel Fernandez Montecelo had been actively committing until his - commit access was removed by Daniel Hartwig. - - Manuel Fernandez Montecelo and Daniel Hartwig took over development - of Aptitude in 2011 with the support of Christian Perrier, an admin - for the Aptitude alioth project. - - There was friction between Manuel Fernandez Montecelo and Daniel - Hartwig, which eventually resulted in Manuel Fernandez Montecelo's - commit access being revoked by Daniel Hartwig. - - Since then, Daniel Hartwig has become inactive, and did not comment - on the issue when requested by the Technical Committee. - -2. During the discussion of this issue, Christian Perrier proposed - that he and Axel Beckert could watch the social aspects of Aptitude - development and restore Manuel Fernandez Montecelo's commit access. - - Christian still has administrative rights and believes he has the - technical power to implement his proposal, but requested the advice - of the technical committee before doing so. - -Using the power of the technical committee to provide advice (§6.1.5): - -1. The Technical Committee agrees that Christian has the power to - implement his proposal and encourages him to do so. - -2. We hope that Christian and Axel will work to manage the social - aspects of the Aptitude project, working to recruit new developers, - building a stronger Aptitude development community, and - establishing policies and procedures that promote a collaborative - team. - -3. We thank Manuel Fernandez Montecelo for bringing this matter to our - attention and apologize for our delay in resolving this matter. diff --git a/762194_automatic_switch_to_systemd/decision b/762194_automatic_switch_to_systemd/decision deleted file mode 100644 index 503b46e..0000000 --- a/762194_automatic_switch_to_systemd/decision +++ /dev/null @@ -1,59 +0,0 @@ -===== TITLE - -Transition plan to systemd by default - -===== WEB SUMMARY - -The committe states that it is in agreement with the transition plan -proposed by the systemd maintainers, and appreciates the effort of -Debian Developers and contributors to mitigate any issues with the -transition - -===== EMAIL INTRO - -In #762194, the Technical Committee was asked to consider the -transition plan of the init package maintainers to have both new -installs and upgrades use systemd by default. - -1. The CTTE determined in #727708 that systemd should be the default - init system in Debian. - -2. In https://lists.debian.org/87mwc9gfsw.fsf@xoog.err.no, the - maintainers of the init package announced their transition plan for - migrating to systemd as the default init system on both installs - and new upgrades. - -3. The init package (and other related packages) currently in jessie - implement this transition. - -===== EMAIL EPILOGUE - -The committe would like to thank everyone who participated in the -discussion of #762194. - -===== DECISION - -Using its power under §6.1.5 to make statements: - -3. The CTTE affirms the decision of the init system package - maintainers to transition to systemd by default on upgrades and to - install systemd by default on new installs. - -4. The CTTE appreciates the effort of Debian contributors to mitigate - any issues with the transition by: - - a) Providing a fallback boot entry for sysvinit when systemd is the - default init in grub (#757298) - - b) Developing a mechanism to warn on inittab configurations which - are unsupported in systemd. (#761063) - - c) Providing documentation on how to remain with sysvinit on - upgrades and switch to sysvinit upon installation. - - d) Numerous bug reports and fixes by contributors who have tested - the systemd migration in their configurations. - -5. The CTTE advises (without overriding any Debian contributor, - maintainer, or team) that any such mitigations should be included - in jessie, to ensure a smooth transition for Debian users. diff --git a/762194_automatic_switch_to_systemd/draft.txt b/762194_automatic_switch_to_systemd/draft.txt deleted file mode 100644 index c02bc50..0000000 --- a/762194_automatic_switch_to_systemd/draft.txt +++ /dev/null @@ -1,26 +0,0 @@ -0. We offer advice and make our views known (Constitution 6.1(5): - -1. The Technical Committee decision in February, selecting systemd as - the default init system for Linux, should not be read as a decision - that existing systems should be automatically switched to systemd. - -2. The Technical Committee has been asked to decide whether existing - Debian GNU/Linux systems should be automatically switched to systemd - during a dist-upgrade to jessie. - -3. We do not want to prejudge, interfere with, or contradict, the - General Resolution process on init systems which is currently - ongoing. Some of the GR options imply that automatic switching - (both during upgrades, and during leaf package installations) will - be necessary in at least some circumstances. - -4. For the moment, we invite concrete proposals for technical changes - which would arrange that 1. new jessie installations using Linux - would get systemd but 2. existing installations retain their - existing init system so far as possible. - -5. After the result of the General Resolution is known, we intend to - formally resolve the question of automatic switching of init - systems. Our decision on that question will of course be - consistent with the successful General Resolution option, whatever - that may be. diff --git a/762194_automatic_switch_to_systemd/draft_dla.txt b/762194_automatic_switch_to_systemd/draft_dla.txt deleted file mode 100644 index 695a3c6..0000000 --- a/762194_automatic_switch_to_systemd/draft_dla.txt +++ /dev/null @@ -1,41 +0,0 @@ -In #762194, the Technical Committee was asked to consider the -transition plan of the init package maintainers to have both new -installs and upgrades use systemd by default. - -1. The CTTE determined in #727708 that systemd should be the default - init system in Debian. - -2. In https://lists.debian.org/87mwc9gfsw.fsf@xoog.err.no, the - maintainers of the init package announced their transition plan for - migrating to systemd as the default init system on both installs - and new upgrades. - -3. The init package (and other related packages) currently in jessie - implement this transition. - -==OPTION A== - -Using its power under §6.1.5 to make statements: - -3. The CTTE affirms the decision of the init system package - maintainers to transition to systemd by default on upgrades and to - install systemd by default on new installs. - -4. The CTTE appreciates the effort of Debian contributors to mitigate - any issues with the transition by: - - a) Providing a fallback boot entry for sysvinit when systemd is the - default init in grub (#757298) - - b) Developing a mechanism to warn on inittab configurations which - are unsupported in systemd. (#761063) - - c) Providing documentation on how to remain with sysvinit on - upgrades and switch to sysvinit upon installation. - - d) Numerous bug reports and fixes by contributors who have tested - the systemd migration in their configurations. - -5. The CTTE advises (without overriding any Debian contributor, - maintainer, or team) that any such mitigations should be included - in jessie, to ensure a smooth transition for Debian users. diff --git a/769972_new_ctte_members/call_for_nominations.txt b/769972_new_ctte_members/call_for_nominations.txt deleted file mode 100644 index 9a1d569..0000000 --- a/769972_new_ctte_members/call_for_nominations.txt +++ /dev/null @@ -1,26 +0,0 @@ -To: debian-devel-announce@lists.debian.org -Subject: Call for nominations for technical committee seats - -First and foremost, the technical committee would like to thank Russ -Allbery and Colin Watson for serving on the committee in addition to -their many other services to Debian. With Russ's resignation[1] and -Colin's planned resignation[2] from the technical committee, there -will be two empty seats which can be filled. - -To fill this seat, we are soliciting nominations. To nominate yourself -or someone else, please send e-mail to debian-ctte-private@debian.org -with the subject "CTTE Nomination of loginname", where loginname is -the nominee's Debian account login.[3] Please let us know in the body -of the e-mail why the nominee would be a good fit for the committee, -specifically instances where the nominee was able to help resolve -disagreements, both technical and non-technical, which you were a -party to or observer of. - -We anticipate starting our selection process on or about the first of -December. After the selection, the committee will then recommend -nominees to the project leader, who may appoint the nominees (§6.2). - - -1: https://lists.debian.org/msgid-search/87k32ufw4t.fsf@hope.eyrie.org -2: https://lists.debian.org/msgid-search/20141108125140.GA7121@riva.ucam.org -3: See http://db.debian.org/ if you need to look the login up diff --git a/769972_new_ctte_members/nomination_confirmation.txt b/769972_new_ctte_members/nomination_confirmation.txt deleted file mode 100644 index d2358e1..0000000 --- a/769972_new_ctte_members/nomination_confirmation.txt +++ /dev/null @@ -1,15 +0,0 @@ -From: Don Armstrong -To: -Cc: debian-ctte-private@debian.org -Reply-To: debian-ctte-private@debian.org -Subject: CTTE Nomination accept/decline - -You have been nominated by someone other than yourself to be -considered for appointment to the Debian Technical Committee. - -Please reply to this e-mail indicating if you are (or are not) willing -to be considered for appointment. Names of accepted nominees will be -made public. - --- -Don Armstrong diff --git a/769972_new_ctte_members/thank_nominees.txt b/769972_new_ctte_members/thank_nominees.txt deleted file mode 100644 index 9aa1580..0000000 --- a/769972_new_ctte_members/thank_nominees.txt +++ /dev/null @@ -1,14 +0,0 @@ -From: Don Armstrong -To: debian-devel-announce@lists.debian.org -Subject: CTTE Nominations closed; thanks to all nominees for agreeing to serve -Reply-to: debian-ctte-private@debian.org -Mail-Followup-To: debian-ctte-private@debian.org - -The Technical Committee would like to thank all of the nominees, -especially those who agreed to serve Debian on the Technical -Committee. In addition, we also appreciate the effort of everyone who -nominated someone else and provided information about positive -interactions with those nominees to the Committee. - -The Technical Committee has begun private deliberations, and will -recommend a nominee to the Project Leader for approval under §6.2.2. diff --git a/770789_df_units/decision b/770789_df_units/decision deleted file mode 100644 index fd7a579..0000000 --- a/770789_df_units/decision +++ /dev/null @@ -1,21 +0,0 @@ -===== TITLE - -IEC units in df output - -===== WEB SUMMARY - -The committee declined to override the decision of the maintainer and -upstream not to include i in the units output. - -===== EMAIL INTRO - -===== EMAIL EPILOGUE - -===== DECISION - -In 770789, the Technical Committee was asked to override the decision -of upstream and the maintainer of df to not include i in the units -output when asked for IEC output (2^10). - -The CTTE declines to override the decision of the maintainer and -upstream. diff --git a/770789_df_units/draft.txt b/770789_df_units/draft.txt deleted file mode 100644 index 7593705..0000000 --- a/770789_df_units/draft.txt +++ /dev/null @@ -1,6 +0,0 @@ -In 770789, the Technical Committee was asked to override the decision -of upstream and the maintainer of df to not include i in the units -output when asked for IEC output (2^10). - -The CTTE declines to override the decision of the maintainer and -upstream. diff --git a/770789_df_units/votes.sh b/770789_df_units/votes.sh deleted file mode 100755 index 059eda2..0000000 --- a/770789_df_units/votes.sh +++ /dev/null @@ -1,7 +0,0 @@ -#!/bin/sh -../scripts/pocket-devotee --quorum 2 --option 'A:decline to override' --option 'FD: Further discussion' <= 8-2)'. + +2. The effect of this is that installing some packages which depend + (directly or indirectly) on libpam-systemd can cause a user's init + system to be switched to systemd, even on systems where a user has + deliberately chosen not to use the default init system, and even + when the switch is unnecessary. + +3. Swappping the order of these dependencies would avoid that and has + no harmful effect: + +4. In particular, on systems that already have systemd-sysv installed, + libpam-systemd will still not pull in systemd-shim, thus minimizing + the risk of breakage on systemd systems. However, on systems that + intentionally do not have systemd-sysv installed, the installation + of libpam-systemd will then prefer to pull in systemd-shim and keep + the installed init system rather than switching to systemd-sysv. + +Decision (Constitution 6.1(4)): + +5. We therefore overrule the decision of the maintainer of + libpam-systemd binary package. The Depends entry + systemd-sysv | systemd-shim (>= 8-2) + should be replaced by + systemd-shim (>= 8-2) | systemd-sysv + +6. For the avoidance of doubt, we do not intend to set this specific + syntax in stone. For example, if in future libpam-systemd needs to + depend on a later systemd-shim, or needs a versioned rather than + unversioned dependency on systemd-sysv, that is fine and would not + contradict our decision. + +Release (Constitution 6.1(5)): + +7. Our advice is that this change should be in jessie. If necessary, + this view should be conveyed to the Release Team, after the change + is in unstable, by filing an unblock request in the usual way. diff --git a/resolved_issues/746578_libpam-systemd_dependencies/draft.txt b/resolved_issues/746578_libpam-systemd_dependencies/draft.txt new file mode 100644 index 0000000..f066fef --- /dev/null +++ b/resolved_issues/746578_libpam-systemd_dependencies/draft.txt @@ -0,0 +1,40 @@ +Rationale (Constitution 6.1(5)): + +1. Currently libpam-systemd (which is pulled in by quite a few + dependency chains) Depends on `systemd-sysv | systemd-shim (>= 8-2)'. + +2. The effect of this is that installing some packages which depend + (directly or indirectly) on libpam-systemd can cause a user's init + system to be switched to systemd, even on systems where a user has + deliberately chosen not to use the default init system, and even + when the switch is unnecessary. + +3. Swappping the order of these dependencies would avoid that and has + no harmful effect: + +4. In particular, on systems that already have systemd-sysv installed, + libpam-systemd will still not pull in systemd-shim, thus minimizing + the risk of breakage on systemd systems. However, on systems that + intentionally do not have systemd-sysv installed, the installation + of libpam-systemd will then prefer to pull in systemd-shim and keep + the installed init system rather than switching to systemd-sysv. + +Decision (Constitution 6.1(4)): + +5. We therefore overrule the decision of the maintainer of + libpam-systemd binary package. The Depends entry + systemd-sysv | systemd-shim (>= 8-2) + should be replaced by + systemd-shim (>= 8-2) | systemd-sysv + +6. For the avoidance of doubt, we do not intend to set this specific + syntax in stone. For example, if in future libpam-systemd needs to + depend on a later systemd-shim, or needs a versioned rather than + unversioned dependency on systemd-sysv, that is fine and would not + contradict our decision. + +Release (Constitution 6.1(5)): + +7. Our advice is that this change should be in jessie. If necessary, + this view should be conveyed to the Release Team, after the change + is in unstable, by filing an unblock request in the usual way. diff --git a/resolved_issues/746715_initsystemfallout/decision b/resolved_issues/746715_initsystemfallout/decision new file mode 100644 index 0000000..02946bc --- /dev/null +++ b/resolved_issues/746715_initsystemfallout/decision @@ -0,0 +1,28 @@ +===== TITLE + +Continuing support for multiple init systems + +===== WEB SUMMARY + +The technical committee expects maintainers to continue to support the +multiple available init systems. + +===== EMAIL INTRO + +The technical committe was asked in #746715 to address the removal of +support for upstart in a package. + +===== EMAIL EPILOGUE + + +===== DECISION + +The issue of init system support recently came to the Technical +Committee's attention again.[1] + +For the record, the TC expects maintainers to continue to support +the multiple available init systems in Debian. That includes +merging reasonable contributions, and not reverting existing +support without a compelling reason. + +[1] See #746715 for background. diff --git a/resolved_issues/746715_initsystemfallout/draft.txt b/resolved_issues/746715_initsystemfallout/draft.txt new file mode 100644 index 0000000..bb0ac88 --- /dev/null +++ b/resolved_issues/746715_initsystemfallout/draft.txt @@ -0,0 +1,9 @@ + The issue of init system support recently came to the Technical + Committee's attention again.[1] + + For the record, the TC expects maintainers to continue to support + the multiple available init systems in Debian. That includes + merging reasonable contributions, and not reverting existing + support without a compelling reason. + + [1] See #746715 for background. diff --git a/resolved_issues/750135_aptitude/decision b/resolved_issues/750135_aptitude/decision new file mode 100644 index 0000000..f450905 --- /dev/null +++ b/resolved_issues/750135_aptitude/decision @@ -0,0 +1,58 @@ +===== TITLE + +Aptitude Project Maintainer + +===== WEB SUMMARY + +The technical committee encorages Christian Perrier to implement his +proposal for maintenance of the Aptitude project. + +===== EMAIL INTRO + +The technical committee was asked in #750135 to address who would +maintain the Aptitude project. + +===== EMAIL EPILOGUE + +===== DECISION + +Background/Rationale: + +1. In #750135, the Technical Committee was asked by Manuel Fernandez + Montecelo who should be the maintainer of the Aptitude project. + + Manuel Fernandez Montecelo had been actively committing until his + commit access was removed by Daniel Hartwig. + + Manuel Fernandez Montecelo and Daniel Hartwig took over development + of Aptitude in 2011 with the support of Christian Perrier, an admin + for the Aptitude alioth project. + + There was friction between Manuel Fernandez Montecelo and Daniel + Hartwig, which eventually resulted in Manuel Fernandez Montecelo's + commit access being revoked by Daniel Hartwig. + + Since then, Daniel Hartwig has become inactive, and did not comment + on the issue when requested by the Technical Committee. + +2. During the discussion of this issue, Christian Perrier proposed + that he and Axel Beckert could watch the social aspects of Aptitude + development and restore Manuel Fernandez Montecelo's commit access. + + Christian still has administrative rights and believes he has the + technical power to implement his proposal, but requested the advice + of the technical committee before doing so. + +Using the power of the technical committee to provide advice (§6.1.5): + +1. The Technical Committee agrees that Christian has the power to + implement his proposal and encourages him to do so. + +2. We hope that Christian and Axel will work to manage the social + aspects of the Aptitude project, working to recruit new developers, + building a stronger Aptitude development community, and + establishing policies and procedures that promote a collaborative + team. + +3. We thank Manuel Fernandez Montecelo for bringing this matter to our + attention and apologize for our delay in resolving this matter. diff --git a/resolved_issues/750135_aptitude/draft b/resolved_issues/750135_aptitude/draft new file mode 100644 index 0000000..07dfcfb --- /dev/null +++ b/resolved_issues/750135_aptitude/draft @@ -0,0 +1,40 @@ +Background/Rationale: + +1. In #750135, the Technical Committee was asked by Manuel Fernandez + Montecelo who should be the maintainer of the Aptitude project. + + Manuel Fernandez Montecelo had been actively committing until his + commit access was removed by Daniel Hartwig. + + Manuel Fernandez Montecelo and Daniel Hartwig took over development + of Aptitude in 2011 with the support of Christian Perrier, an admin + for the Aptitude alioth project. + + There was friction between Manuel Fernandez Montecelo and Daniel + Hartwig, which eventually resulted in Manuel Fernandez Montecelo's + commit access being revoked by Daniel Hartwig. + + Since then, Daniel Hartwig has become inactive, and did not comment + on the issue when requested by the Technical Committee. + +2. During the discussion of this issue, Christian Perrier proposed + that he and Axel Beckert could watch the social aspects of Aptitude + development and restore Manuel Fernandez Montecelo's commit access. + + Christian still has administrative rights and believes he has the + technical power to implement his proposal, but requested the advice + of the technical committee before doing so. + +Using the power of the technical committee to provide advice (§6.1.5): + +1. The Technical Committee agrees that Christian has the power to + implement his proposal and encourages him to do so. + +2. We hope that Christian and Axel will work to manage the social + aspects of the Aptitude project, working to recruit new developers, + building a stronger Aptitude development community, and + establishing policies and procedures that promote a collaborative + team. + +3. We thank Manuel Fernandez Montecelo for bringing this matter to our + attention and apologize for our delay in resolving this matter. diff --git a/resolved_issues/762194_automatic_switch_to_systemd/decision b/resolved_issues/762194_automatic_switch_to_systemd/decision new file mode 100644 index 0000000..503b46e --- /dev/null +++ b/resolved_issues/762194_automatic_switch_to_systemd/decision @@ -0,0 +1,59 @@ +===== TITLE + +Transition plan to systemd by default + +===== WEB SUMMARY + +The committe states that it is in agreement with the transition plan +proposed by the systemd maintainers, and appreciates the effort of +Debian Developers and contributors to mitigate any issues with the +transition + +===== EMAIL INTRO + +In #762194, the Technical Committee was asked to consider the +transition plan of the init package maintainers to have both new +installs and upgrades use systemd by default. + +1. The CTTE determined in #727708 that systemd should be the default + init system in Debian. + +2. In https://lists.debian.org/87mwc9gfsw.fsf@xoog.err.no, the + maintainers of the init package announced their transition plan for + migrating to systemd as the default init system on both installs + and new upgrades. + +3. The init package (and other related packages) currently in jessie + implement this transition. + +===== EMAIL EPILOGUE + +The committe would like to thank everyone who participated in the +discussion of #762194. + +===== DECISION + +Using its power under §6.1.5 to make statements: + +3. The CTTE affirms the decision of the init system package + maintainers to transition to systemd by default on upgrades and to + install systemd by default on new installs. + +4. The CTTE appreciates the effort of Debian contributors to mitigate + any issues with the transition by: + + a) Providing a fallback boot entry for sysvinit when systemd is the + default init in grub (#757298) + + b) Developing a mechanism to warn on inittab configurations which + are unsupported in systemd. (#761063) + + c) Providing documentation on how to remain with sysvinit on + upgrades and switch to sysvinit upon installation. + + d) Numerous bug reports and fixes by contributors who have tested + the systemd migration in their configurations. + +5. The CTTE advises (without overriding any Debian contributor, + maintainer, or team) that any such mitigations should be included + in jessie, to ensure a smooth transition for Debian users. diff --git a/resolved_issues/762194_automatic_switch_to_systemd/draft.txt b/resolved_issues/762194_automatic_switch_to_systemd/draft.txt new file mode 100644 index 0000000..c02bc50 --- /dev/null +++ b/resolved_issues/762194_automatic_switch_to_systemd/draft.txt @@ -0,0 +1,26 @@ +0. We offer advice and make our views known (Constitution 6.1(5): + +1. The Technical Committee decision in February, selecting systemd as + the default init system for Linux, should not be read as a decision + that existing systems should be automatically switched to systemd. + +2. The Technical Committee has been asked to decide whether existing + Debian GNU/Linux systems should be automatically switched to systemd + during a dist-upgrade to jessie. + +3. We do not want to prejudge, interfere with, or contradict, the + General Resolution process on init systems which is currently + ongoing. Some of the GR options imply that automatic switching + (both during upgrades, and during leaf package installations) will + be necessary in at least some circumstances. + +4. For the moment, we invite concrete proposals for technical changes + which would arrange that 1. new jessie installations using Linux + would get systemd but 2. existing installations retain their + existing init system so far as possible. + +5. After the result of the General Resolution is known, we intend to + formally resolve the question of automatic switching of init + systems. Our decision on that question will of course be + consistent with the successful General Resolution option, whatever + that may be. diff --git a/resolved_issues/762194_automatic_switch_to_systemd/draft_dla.txt b/resolved_issues/762194_automatic_switch_to_systemd/draft_dla.txt new file mode 100644 index 0000000..695a3c6 --- /dev/null +++ b/resolved_issues/762194_automatic_switch_to_systemd/draft_dla.txt @@ -0,0 +1,41 @@ +In #762194, the Technical Committee was asked to consider the +transition plan of the init package maintainers to have both new +installs and upgrades use systemd by default. + +1. The CTTE determined in #727708 that systemd should be the default + init system in Debian. + +2. In https://lists.debian.org/87mwc9gfsw.fsf@xoog.err.no, the + maintainers of the init package announced their transition plan for + migrating to systemd as the default init system on both installs + and new upgrades. + +3. The init package (and other related packages) currently in jessie + implement this transition. + +==OPTION A== + +Using its power under §6.1.5 to make statements: + +3. The CTTE affirms the decision of the init system package + maintainers to transition to systemd by default on upgrades and to + install systemd by default on new installs. + +4. The CTTE appreciates the effort of Debian contributors to mitigate + any issues with the transition by: + + a) Providing a fallback boot entry for sysvinit when systemd is the + default init in grub (#757298) + + b) Developing a mechanism to warn on inittab configurations which + are unsupported in systemd. (#761063) + + c) Providing documentation on how to remain with sysvinit on + upgrades and switch to sysvinit upon installation. + + d) Numerous bug reports and fixes by contributors who have tested + the systemd migration in their configurations. + +5. The CTTE advises (without overriding any Debian contributor, + maintainer, or team) that any such mitigations should be included + in jessie, to ensure a smooth transition for Debian users. diff --git a/resolved_issues/769972_new_ctte_members/call_for_nominations.txt b/resolved_issues/769972_new_ctte_members/call_for_nominations.txt new file mode 100644 index 0000000..9a1d569 --- /dev/null +++ b/resolved_issues/769972_new_ctte_members/call_for_nominations.txt @@ -0,0 +1,26 @@ +To: debian-devel-announce@lists.debian.org +Subject: Call for nominations for technical committee seats + +First and foremost, the technical committee would like to thank Russ +Allbery and Colin Watson for serving on the committee in addition to +their many other services to Debian. With Russ's resignation[1] and +Colin's planned resignation[2] from the technical committee, there +will be two empty seats which can be filled. + +To fill this seat, we are soliciting nominations. To nominate yourself +or someone else, please send e-mail to debian-ctte-private@debian.org +with the subject "CTTE Nomination of loginname", where loginname is +the nominee's Debian account login.[3] Please let us know in the body +of the e-mail why the nominee would be a good fit for the committee, +specifically instances where the nominee was able to help resolve +disagreements, both technical and non-technical, which you were a +party to or observer of. + +We anticipate starting our selection process on or about the first of +December. After the selection, the committee will then recommend +nominees to the project leader, who may appoint the nominees (§6.2). + + +1: https://lists.debian.org/msgid-search/87k32ufw4t.fsf@hope.eyrie.org +2: https://lists.debian.org/msgid-search/20141108125140.GA7121@riva.ucam.org +3: See http://db.debian.org/ if you need to look the login up diff --git a/resolved_issues/769972_new_ctte_members/nomination_confirmation.txt b/resolved_issues/769972_new_ctte_members/nomination_confirmation.txt new file mode 100644 index 0000000..d2358e1 --- /dev/null +++ b/resolved_issues/769972_new_ctte_members/nomination_confirmation.txt @@ -0,0 +1,15 @@ +From: Don Armstrong +To: +Cc: debian-ctte-private@debian.org +Reply-To: debian-ctte-private@debian.org +Subject: CTTE Nomination accept/decline + +You have been nominated by someone other than yourself to be +considered for appointment to the Debian Technical Committee. + +Please reply to this e-mail indicating if you are (or are not) willing +to be considered for appointment. Names of accepted nominees will be +made public. + +-- +Don Armstrong diff --git a/resolved_issues/769972_new_ctte_members/thank_nominees.txt b/resolved_issues/769972_new_ctte_members/thank_nominees.txt new file mode 100644 index 0000000..9aa1580 --- /dev/null +++ b/resolved_issues/769972_new_ctte_members/thank_nominees.txt @@ -0,0 +1,14 @@ +From: Don Armstrong +To: debian-devel-announce@lists.debian.org +Subject: CTTE Nominations closed; thanks to all nominees for agreeing to serve +Reply-to: debian-ctte-private@debian.org +Mail-Followup-To: debian-ctte-private@debian.org + +The Technical Committee would like to thank all of the nominees, +especially those who agreed to serve Debian on the Technical +Committee. In addition, we also appreciate the effort of everyone who +nominated someone else and provided information about positive +interactions with those nominees to the Committee. + +The Technical Committee has begun private deliberations, and will +recommend a nominee to the Project Leader for approval under §6.2.2. diff --git a/resolved_issues/770789_df_units/decision b/resolved_issues/770789_df_units/decision new file mode 100644 index 0000000..fd7a579 --- /dev/null +++ b/resolved_issues/770789_df_units/decision @@ -0,0 +1,21 @@ +===== TITLE + +IEC units in df output + +===== WEB SUMMARY + +The committee declined to override the decision of the maintainer and +upstream not to include i in the units output. + +===== EMAIL INTRO + +===== EMAIL EPILOGUE + +===== DECISION + +In 770789, the Technical Committee was asked to override the decision +of upstream and the maintainer of df to not include i in the units +output when asked for IEC output (2^10). + +The CTTE declines to override the decision of the maintainer and +upstream. diff --git a/resolved_issues/770789_df_units/draft.txt b/resolved_issues/770789_df_units/draft.txt new file mode 100644 index 0000000..7593705 --- /dev/null +++ b/resolved_issues/770789_df_units/draft.txt @@ -0,0 +1,6 @@ +In 770789, the Technical Committee was asked to override the decision +of upstream and the maintainer of df to not include i in the units +output when asked for IEC output (2^10). + +The CTTE declines to override the decision of the maintainer and +upstream. diff --git a/resolved_issues/770789_df_units/votes.sh b/resolved_issues/770789_df_units/votes.sh new file mode 100755 index 0000000..059eda2 --- /dev/null +++ b/resolved_issues/770789_df_units/votes.sh @@ -0,0 +1,7 @@ +#!/bin/sh +../scripts/pocket-devotee --quorum 2 --option 'A:decline to override' --option 'FD: Further discussion' <