+++ /dev/null
-* 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
+++ /dev/null
- 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.
+++ /dev/null
-===== 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
+++ /dev/null
- 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.)
+++ /dev/null
-===== 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.
-
+++ /dev/null
-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:
+++ /dev/null
-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.
+++ /dev/null
-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.
+++ /dev/null
-# 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
+++ /dev/null
-===== 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.
+++ /dev/null
-===== 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.
+++ /dev/null
-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.
+++ /dev/null
-===== 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.
+++ /dev/null
- 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.
+++ /dev/null
-===== 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.
+++ /dev/null
-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.
+++ /dev/null
-===== 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.
+++ /dev/null
-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.
+++ /dev/null
-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.
+++ /dev/null
-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
+++ /dev/null
-From: Don Armstrong <don@debian.org>
-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
+++ /dev/null
-From: Don Armstrong <don@debian.org>
-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.
+++ /dev/null
-===== 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.
+++ /dev/null
-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.
+++ /dev/null
-#!/bin/sh
-../scripts/pocket-devotee --quorum 2 --option 'A:decline to override' --option 'FD: Further discussion' <<EOF
-don: A, FD
-steve: A, FD
-keith: A, FD
-bdale: A, FD
-EOF
--- /dev/null
+* 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
--- /dev/null
+ 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.
--- /dev/null
+===== 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
--- /dev/null
+ 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.)
--- /dev/null
+===== 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.
+
--- /dev/null
+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:
--- /dev/null
+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.
--- /dev/null
+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.
--- /dev/null
+# 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
--- /dev/null
+===== 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.
--- /dev/null
+===== 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.
--- /dev/null
+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.
--- /dev/null
+===== 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.
--- /dev/null
+ 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.
--- /dev/null
+===== 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.
--- /dev/null
+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.
--- /dev/null
+===== 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.
--- /dev/null
+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.
--- /dev/null
+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.
--- /dev/null
+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
--- /dev/null
+From: Don Armstrong <don@debian.org>
+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
--- /dev/null
+From: Don Armstrong <don@debian.org>
+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.
--- /dev/null
+===== 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.
--- /dev/null
+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.
--- /dev/null
+#!/bin/sh
+../scripts/pocket-devotee --quorum 2 --option 'A:decline to override' --option 'FD: Further discussion' <<EOF
+don: A, FD
+steve: A, FD
+keith: A, FD
+bdale: A, FD
+EOF
projects / debian-ctte.git / commitdiff