+++ /dev/null
-* Issue http://bugs.debian.org/681783 http://bugs.debian.org/681834
-** gnome-core Depends: on network-manager which prevents network-manager from being easily replaced with wicd or similar
-** Are Depends: appropriate for metapackages
-** Is running with recommends off supported
-* Possible Solutions
-** Punt to policy
-** Ian to write up statement about Recommends
-* Open Questions
-** Appears to be general instead of specific to network-manager and the gnome metapackage
-* Proposed Resolutions
-** http://lists.debian.org/msgid-search/20514.35772.350203.926582@chiark.greenend.org.uk
-** http://lists.debian.org/msgid-search/87k3x9royz.fsf@windlord.stanford.edu
-* Adopted Resolution
-* Involved Parties
-** gnome-core@packages.debian.org, 681834@bugs.debian.org, 681783@bugs.debian.org
+++ /dev/null
-wip wip wip do not use
-
-===== TITLE
-
-Dependency from gnome-core to network-manager
-
-===== WEB SUMMARY
-
-gnome-core should Recommend, not Depend, on network-manager
-(overrule maintainer).
-
-===== EMAIL INTRO
-
-The dependency from gnome-core to network-manager (via
-network-manager-gnome) was referred to the Technical Committee.
-
-The TC has made the following decision:
-
-===== DECISION
-
-Whereas:
-
-1. The gnome-core metapackage is intended to reflect the core of the
- GNOME desktop environment: the basic tools and subsystems that
- together constitute GNOME. The gnome metapackage is intended to
- reflect the broader desktop environment, including extra components
- and applications.
-
-2. network-manager is the GNOME network control system, and is
- recommended for most GNOME users. Some Debian GNOME users don't like
- some of network-manager's behavior and prefer to instead use other
- tools, either basic ifupdown or other frameworks such as wicd.
-
-3. In squeeze, the gnome metapackage lists network-manager in Recommends
- but not Depends. In wheezy, currently, network-manager has moved from
- gnome to gnome-core, and from Recommends to Depends. This represents
- a substantially increased insistance that users of the GNOME
- metapackages have network-manager installed; specifically, there is no
- longer any way to install any but the most minimal GNOME metapackage
- (gnome-session) without installing network-manager, and users who have
- gnome or gnome-core installed but have removed or never installed
- network-manager will have network-manager installed during an upgrade
- from squeeze.
-
-4. For most applications and components, the only drawback of this would
- be some additional disk space usage, since the application, despite
- being installed, wouldn't need to be used. However, network-manager
- assumes that, if it is installed, it should attempt to manage the
- system's network configuration. It attempts to avoid overriding local
- manual configuration, but it isn't able to detect all cases where the
- user is using some other component or system to manage networking.
- The user has to take separate, explicit (and somewhat unusual for the
- average user) action to disable network-manager after it has been
- installed.
-
-5. The Technical Committee believes that this will cause undesireable
- behavior for upgrades from squeeze, and (of somewhat lesser
- importance) will make it more difficult than necessary for GNOME users
- to swap network management components, something for which there
- appears to be noticable demand. We therefore believe that
- network-manager should be moved to Recommends in gnome-core.
-
-6. Please note that this is not a general statement about GNOME
- components. It is very specific to network-manager because all of the
- following apply:
-
- (i) The package takes action automatically because it is installed,
- rather than being a component that can either be run or not at the
- user's choice.
-
- (ii) The package has historically been recommended rather than listed
- as a dependency, so existing Debian users are used to that
- behavior and will expect it to be preserved during upgrades.
-
- (ii) There is both demonstrable, intentional widespread replacement of
- that package by Debian GNOME users and no significant loss of
- unrelated GNOME desktop functionality by replacing it with a
- different component.
-
- If any of these points did not apply, the situation would be
- significantly different.
-
-Therefore:
-
-7. The Technical Committee overrules the decision of the gnome-core
- metapackage maintainers. The dependency from gnome-core to
- network-manager-gnome should be downgraded to Recommends.
-
-8. The Technical Committee requests that the Release Managers unblock
- the update to implement this decision, so that this change may be
- released in wheezy.
-
-===== EMAIL EPILOGUE
-===== # processor will insert "Please see http://..." for the TC bug.
-===== # mentioning bug urls here will result in a "see also" on the web page
-
-http://bugs.debian.org/645656 (against gnome-core) will be used to
-track the the implementation of this decision.
-
-Along with the specific case of gnome-core and network-manager, the TC
-also considered the policy on use of Recommends more generally,
-particularly in the context of metapackages; this was also discussed
-and resulted in a TC decision which can be found at
-http://bugs.debian.org/681783.
+++ /dev/null
- Whereas:
-
- 1. Our technical objectives are:
-
- (i) Users who do not do anything special should get
- network-manager along with gnome (in this case, along with
- gnome-core). These users should continue to have
- network-manager installed, across upgrades.
-
- (ii) Users should be able to conveniently install and upgrade
- gnome without network-manager.
-
- (iii) Users who deliberately removed network-manager in squeeze
- (which they will generally have done by deliberately violating
- the Recommends from the gnome metapackage) should not have to
- do anything special to avoid it coming back in wheezy.
-
- (iv) Users who do make a decision that they do not want to use
- network-manager should not have to read specific
- documentation, or temporarily have network-manager installed,
- risk being exposed to bugs in network-manager's configuration
- arrangements, and so on.
-
- 2. Our technical objectives do NOT include:
-
- (i) The `gnome-core' metapackage should in some sense perfectly or
- exactly correspond to GNOME upstream's definition of `the GNOME
- Core', specifically including every such component as a hard
- Depends.
-
- (ii) The contents of any metapackage should be the correct
- expression of the subjective opinion of the metapackage's
- maintainer.
-
- (iii) Users who choose to globally disable Recommends should still
- get the desired behaviours as described above in point 1.
-
- 3. The solution recommended by the gnome-core maintainers is
- that users who do not wish to use network-manager should have it
- installed but disable it.
-
- Installing network-manager in these circumstances does
- not fully meet any of the above objectives apart from 1(i).
-
- 5. The alternative solution rejected by the gnome-core maintainers
- is downgrade the dependency to Recommends.
-
- This solution meets all of the objectives from point 1, except
- that infelicities in teh package manager may mean that the user
- in 1(iii) may need to take action to prevent network-manager
- being reinstalled during an upgrade.
-
- Therefore:
-
- 6. The Technical Committee overrules the decision of the gnome-core
- metapackage maintainer. The dependency from gnome-core to
- network-manager-gnome should be downgraded to Recommends.
-
- 7. The Technical Committee requests that the Release Managers
- unblock the update to implement this decision, so that this
- change may be released in wheezy.
+++ /dev/null
- The gnome-core metapackage is intended to reflect the core of the
- GNOME desktop environment: the basic tools and subsystems that
- together constitute GNOME. The gnome metapackage is intended to
- reflect the broader desktop environment, including extra components
- and applications.
-
- network-manager is the GNOME network control system, and is
- recommended for most GNOME users. Some Debian GNOME users don't like
- some of network-manager's behavior and prefer to instead use other
- tools, either basic ifupdown or other frameworks such as wicd.
-
- In squeeze, the gnome metapackage lists network-manager in Recommends
- but not Depends. In wheezy, currently, network-manager has moved from
- gnome to gnome-core, and from Recommends to Depends. This represents
- a substantially increased insistance that users of the GNOME
- metapackages have network-manager installed. This change is, so far
- as the Technical Committee understands, driven primarily by user
- confusion and bug reports, but does not reflect a deeper or tighter
- integration of network-manager into GNOME than was the case in
- squeeze.
-
- If matters are left as they currently stand, users who have the gnome
- metapackages installed but do not have network-manager installed will,
- in the process of upgrading from squeeze to wheezy (either due to an
- explicit decision to remove it or an implicit decision to not install
- it by disabling automatic installation of Recommends), end up
- installing network-manager on systems where it is currently not
- installed. It will also no longer be possible for users to install
- GNOME metapackages in wheezy without installing network-manager.
-
- For most applications and components, the only drawback of this would
- be some additional disk space usage, since the application, despite
- being installed, wouldn't need to be used. However, network-manager
- assumes that, if it is installed, it should attempt to manage the
- system's network configuration. It attempts to avoid overriding local
- manual configuration, but it isn't able to detect all cases where the
- user is using some other component or system to manage networking.
- The user has to take separate, explicit (and somewhat unusual for the
- average user) action to disable network-manager after it has been
- installed.
-
- The Technical Committee believes that this will cause undesireable
- behavior for upgrades from squeeze, and (of somewhat lesser
- importance) will make it more difficult than necessary for GNOME users
- to swap network management components, something for which there
- appears to be noticable demand. We therefore believe that
- network-manager should be either moved to Recommends in gnome-core, or
- moved from the gnome-core metapackage to the gnome metapackage (which
- is defined as including additional, optional components).
-
- Please note that this is not a general statement about GNOME
- components. It is very specific to network-manager because all of the
- following apply:
-
- 1. The package takes action automatically because it is installed,
- rather than being a component that can either be run or not at the
- user's choice.
-
- 2. The package has historically been recommended rather than listed as
- a dependency, so existing Debian users are used to that behavior.
-
- 3. There is both demonstrable, intentional widespread replacement of
- that package by Debian GNOME users and no significant loss of
- unrelated GNOME desktop functionality by replacing it with a
- different component.
-
- If any of these points did not apply, the situation would be
- significantly different.
+++ /dev/null
- Whereas:
-
- 1. The gnome-core metapackage is intended to reflect the core of the
- GNOME desktop environment: the basic tools and subsystems that
- together constitute GNOME. The gnome metapackage is intended to
- reflect the broader desktop environment, including extra components
- and applications.
-
- 2. network-manager is the GNOME network control system, and is
- recommended for most GNOME users. Some Debian GNOME users don't like
- some of network-manager's behavior and prefer to instead use other
- tools, either basic ifupdown or other frameworks such as wicd.
-
- 3. In squeeze, the gnome metapackage lists network-manager in Recommends
- but not Depends. In wheezy, currently, network-manager has moved from
- gnome to gnome-core, and from Recommends to Depends. This represents
- a substantially increased insistance that users of the GNOME
- metapackages have network-manager installed. This change does
- not reflect, so far as the Technical Committee understands, a
- deeper or tighter integration of network-manager into GNOME than
- was the case in squeeze.
-
- 4. If matters are left as they currently stand, users who have the
- gnome metapackages installed but do not have network-manager
- installed (either due to an explicit decision to remove it or an
- implicit decision to not install it by disabling automatic
- installation of Recommends) will, in the process of upgrading from
- squeeze to wheezy, end up installing network-manager on systems
- where it is currently not installed. It will also no longer be
- possible for users to install GNOME metapackages in wheezy without
- installing network-manager.
-
- 5. For most applications and components, the only drawback of this would
- be some additional disk space usage, since the application, despite
- being installed, wouldn't need to be used. However, network-manager
- assumes that, if it is installed, it should attempt to manage the
- system's network configuration. It attempts to avoid overriding local
- manual configuration, but it isn't able to detect all cases where the
- user is using some other component or system to manage networking.
- The user has to take separate, explicit (and somewhat unusual for the
- average user) action to disable network-manager after it has been
- installed.
-
- 6. The Technical Committee believes that this will cause undesireable
- behavior for upgrades from squeeze, and (of somewhat lesser
- importance) will make it more difficult than necessary for GNOME users
- to swap network management components, something for which there
- appears to be noticable demand. We therefore believe that
- network-manager should be moved to Recommends in gnome-core.
-
- 7. Please note that this is not a general statement about GNOME
- components. It is very specific to network-manager because all of the
- following apply:
-
- (i) The package takes action automatically because it is installed,
- rather than being a component that can either be run or not at the
- user's choice.
-
- (ii) The package has historically been recommended rather than listed as
- a dependency, so existing Debian users are used to that behavior.
-
- (ii) There is both demonstrable, intentional widespread replacement of
- that package by Debian GNOME users and no significant loss of
- unrelated GNOME desktop functionality by replacing it with a
- different component.
-
- 8. If any of these points did not apply, the situation would be
- significantly different.
-
- Therefore:
-
- 9. The Technical Committee overrules the decision of the gnome-core
- metapackage maintainers. The dependency from gnome-core to
- network-manager-gnome should be downgraded to Recommends.
-
- 10. The Technical Committee requests that the Release Managers
- unblock the update to implement this decision, so that this
- change may be released in wheezy.
+++ /dev/null
- Whereas:
-
- 1. The gnome-core metapackage is intended to reflect the core of the
- GNOME desktop environment: the basic tools and subsystems that
- together constitute GNOME. The gnome metapackage is intended to
- reflect the broader desktop environment, including extra components
- and applications.
-
- 2. network-manager is the GNOME network control system, and is
- recommended for most GNOME users. Some Debian GNOME users don't like
- some of network-manager's behavior and prefer to instead use other
- tools, either basic ifupdown or other frameworks such as wicd.
-
- 3. In squeeze, the gnome metapackage lists network-manager in Recommends
- but not Depends. In wheezy, currently, network-manager has moved from
- gnome to gnome-core, and from Recommends to Depends. This represents
- a substantially increased insistance that users of the GNOME
- metapackages have network-manager installed; specifically, there is no
- longer any way to install any but the most minimal GNOME metapackage
- (gnome-session) without installing network-manager, and users who have
- gnome or gnome-core installed but have removed or never installed
- network-manager will have network-manager installed during an upgrade
- from squeeze.
-
- 4. For most applications and components, the only drawback of this would
- be some additional disk space usage, since the application, despite
- being installed, wouldn't need to be used. However, network-manager
- assumes that, if it is installed, it should attempt to manage the
- system's network configuration. It attempts to avoid overriding local
- manual configuration, but it isn't able to detect all cases where the
- user is using some other component or system to manage networking.
- The user has to take separate, explicit (and somewhat unusual for the
- average user) action to disable network-manager after it has been
- installed.
-
- 5. The Technical Committee believes that this will cause undesireable
- behavior for upgrades from squeeze, and (of somewhat lesser
- importance) will make it more difficult than necessary for GNOME users
- to swap network management components, something for which there
- appears to be noticable demand. We therefore believe that
- network-manager should be moved to Recommends in gnome-core.
-
- 6. Please note that this is not a general statement about GNOME
- components. It is very specific to network-manager because all of the
- following apply:
-
- (i) The package takes action automatically because it is installed,
- rather than being a component that can either be run or not at the
- user's choice.
-
- (ii) The package has historically been recommended rather than listed
- as a dependency, so existing Debian users are used to that
- behavior and will expect it to be preserved during upgrades.
-
- (ii) There is both demonstrable, intentional widespread replacement of
- that package by Debian GNOME users and no significant loss of
- unrelated GNOME desktop functionality by replacing it with a
- different component.
-
- If any of these points did not apply, the situation would be
- significantly different.
-
- Therefore:
-
- 7. The Technical Committee overrules the decision of the gnome-core
- metapackage maintainers. The dependency from gnome-core to
- network-manager-gnome should be downgraded to Recommends.
-
- 8. The Technical Committee requests that the Release Managers unblock
- the update to implement this decision, so that this change may be
- released in wheezy.
+++ /dev/null
-To: debian-devel-announce@lists.debian.org
-Subject: Call for nominations for technical committee seat
-
-First and foremost, the technical committee would like to thank Manoj
-Srivastava for serving on the committee in addition to his many other
-services to Debian. With his resignation from the technical
-committee,[1] there is currently one empty seat 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.[2] 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
-October. After the selection, the committee will then recommend a
-nominee to the project leader, who may appoint the nominee (§6.2).
-
-
-1: http://lists.debian.org/msgid-search/502808CD.3090508@golden-gryphon.com
-2: See http://db.debian.org/ if you need to look the login up
+++ /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 following
-nominees for agreeing to serve Debian on the Technical Committee:
-
-<<list of nominees>>
-
-The Technical Committee has begun private deliberations, and will
-recommend a nominee to the Project Leader for approval under §6.2.2.
-
-Anyone who wishes to submit information about any of the nominees
-(both praise and concerns) should e-mail
-debian-ctte-private@debian.org, and the CTTE will take the information
-into account.
-
+++ /dev/null
-===== TITLE
-
-Dependency of meta-gnome on network-manager
-
-===== WEB SUMMARY
-
-The committee overrules the dependency of meta-gnome on
-network-manager while concerns raised in <a
-href="http://bugs.debian.org/681834#273">§4 of the decision in
-#681834</a> remain unaddressed.
-
-===== EMAIL INTRO
-
-The technical committee was asked in #688772 to revisit the dependency
-of gnome metapackages on network-manager. The decision is below:
-
-===== EMAIL EPILOGUE
-
-The committee would like to thank Michael Biebl for discussing the
-concerns of the technical committee and working to address those
-concerns through technical changes to NM.
-
-===== DECISION
-
-1. The TC notes the decision of the meta-gnome maintainers to
- implement the TC decision in #681834 by:
- (a) softening the dependency in the gnome-core metapackage
- from Depends to Recommends, as required
- (b) adding a new dependency in the gnome metapackage,
- as a Depends. (In squeeze, this is where the dependency
- was, but it was a Recommends.)
-
-2. Our intent, as stated in the rationale section of our previous
- decision (#681834, paras 3 and 5), is that squeeze users who have
- gnome installed but not network-manager do not find that
- network-manager becomes installed when they upgrade to wheezy.
-
-3. A Recommends from gnome to network-manager-gnome would serve no
- purpose in wheezy as gnome Depends on gnome-core which already
- Recommends network-manager-gnome.
-
-Therefore
-
-4. We overrule the decision of the meta-gnome maintainers to add a
- dependency from gnome to network-manager-gnome; this dependency
- should be removed. If in the opinion of the NM maintainer (and
- before the release of wheezy the Chair of the Technical Committee
- or an individual delegated by the Chair in consultation with the
- Release Team) the concerns raised in §4 of the CTTE decision
- #681834 have been addressed through technical means (e.g. by
- preventing the starting of NM as discussed in #688772), the
- meta-gnome maintainers may freely adjust the dependencies as
- usual.
-
- Specifically, valid bugs where existing valid network
- configurations are broken by the automatic, required installation
- on system upgrade of packages not previously installed which
- perform network configuration on should have severity serious.
-
-5. We request that the Release Team unblock update(s) to meta-gnome so
- that our decisions may be implemented in wheezy.
-
-6. We request that a release note is created explaining that gnome
- users who do not currently have NM installed consider installing
- it.
+++ /dev/null
-1. The TC notes the decision of the meta-gnome maintainers to
- implement the TC decision in #681834 by:
- (a) softening the dependency in the gnome-core metapackage
- from Depends to Recommends, as required
- (b) adding a new dependency in the gnome metapackage,
- as a Depends. (In squeeze, this is where the dependency
- was, but it was a Recommends.)
-
-2. Our intent, as stated in the rationale section of our previous
- decision (#681834, paras 3 and 5), is that squeeze users who have
- gnome installed but not network-manager do not find that
- network-manager becomes installed when they upgrade to wheezy.
-
-3. A Recommends from gnome to network-manager-gnome would serve no
- purpose in wheezy as gnome Depends on gnome-core which already
- Recommends network-manager-gnome.
-
-Therefore
-
-A 4. We overrule the decision of the meta-gnome maintainers to add a
-A dependency from gnome to network-manager-gnome; this dependency
-A should be removed for the release of wheezy.
-A
-A 5. We request that the Release Team unblock update(s) to meta-gnome so
-A that our decisions may be implemented in wheezy.
-A
-A 6. We request that a release note is created explaining that gnome
-A users who do not currently have NM installed consider installing
-A it.
-
-
-B 4. We overrule the decision of the meta-gnome maintainers to add a
-B dependency from gnome to network-manager-gnome; this dependency
-B should be removed. If in the opinion of the NM maintainer (and
-B before the release of wheezy the Chair of the Technical Committee
-B or an individual delegated by the Chair in consultation with the
-B Release Team) the concerns raised in §4 of the CTTE decision
-B #681834 have been addressed through technical means (e.g. by
-B preventing the starting of NM as discussed in #688772), the
-B meta-gnome maintainers may freely adjust the dependencies as
-B usual.
-B
-B Specifically, valid bugs where existing valid network
-B configurations are broken by the automatic, required installation
-B on system upgrade of packages not previously installed which
-B perform network configuration on should have severity serious.
-B
-B 5. We request that the Release Team unblock update(s) to meta-gnome so
-B that our decisions may be implemented in wheezy.
-B
-B 6. We request that a release note is created explaining that gnome
-B users who do not currently have NM installed consider installing
-B it.
-
-C 4. After further discussion, we understand that reintroducing
-C network-manager on upgrade was part of the intent, due to both
-C substantial improvements in network-manager and tighter integration of
-C network-manager with the GNOME desktop in wheezy. Since the gnome
-C metapackage has historically been more aggressive at pulling in
-C additional packages, we believe the move of the dependency from
-C gnome-core to gnome is an acceptable compromise that was not raised
-C during the previous discussion. Users who want to remove
-C network-manager can still use the gnome-core metapackage to get the
-C basic GNOME desktop functionality.
-C
-C We recommend that this upgrade behavior for users of the gnome
-C metapackage be documented in the release notes.
+++ /dev/null
-Whereas
-
-1. The TC notes the decision of the meta-gnome maintainers to
- implement our decision in #681834 by:
- (a) softening the dependency in the gnome-core metapackage
- from Depends to Recommends, as required
- (b) adding a new dependency in the gnome metapackage,
- as a Depends. (In squeeze, this is where the dependency
- was, but it was a Recommends.)
-
-2. Our intent, as stated in the rationale section of our previous
- decision (#681834, paras 3 and 5), is that squeeze users who have
- gnome installed but not network-manager do not find that
- network-manager becomes installed when they upgrade to wheezy.
-
-3. The actions of the meta-gnome maintainers do not achieve this
- objective.
-
-4. Insofar as any reasons have been advanced for the meta-gnome
- maintainer's decision, we do not find them convincing.
-
-5. A Recommends from gnome to network-manager-gnome would serve no
- purpose in wheezy as gnome Depends on gnome-core which already
- Recommends network-manager-gnome.
-
-Therefore
-
-6. We overrule the decision of the meta-gnome maintainers to add a
- dependency from gnome to network-manager-gnome. This dependency
- should be removed.
-
-7. We request that the Release Team unblock update(s) to meta-gnome so
- that our decisions may be implemented in wheezy.
-
-8. We specifically forbid anyone from introducing in wheezy, or
- in sid until wheezy is released:
- a. Any new or enhanced dependencies, or any other mechanisms,
- which increase the likelihood of network-manager being
- installed;
- b. Any new or enhanced user-facing warnings, imprecations, or
- other kinds of message regarding the alleged desirability or
- requirement to install network-manager;
- c. Any change which in any way impairs (or further impairs) the
- functioning of systems with GNOME components installed but
- without network-manager;
- d. Any change which is contrary to the spirit or intent of either
- our previous resolution in #681834 or this resolution.
- without first obtaining the permission of at least one member of
- the Technical Committee.
-
-Furthermore
-
-9. It is disappointing that this proposed solution to the problem was
- not mentioned during the TC discussion. If it had been, it could
- have been accepted or rejected by the TC at the time.
-
-10. We remind everyone that the Constitution requires members of the
- project not to work against decisions properly made according to
- the project's governance processes. On this occasion we do not
- feel it necessary to refer anyone to the Debian Account Managers
- asking for a review of their status.
+++ /dev/null
-===== TITLE
-
-Creation of isdn devices by isdnutils
-
-===== WEB SUMMARY
-
-The committee overrules the maintainer of isdnutils to require the
-inclusion of code to create isdn devices by isdnutils.
-
-===== EMAIL INTRO
-
-The technical committee was asked in #698556 to overrule the decision
-of the isdnutils maintainer to remove the creation of devices.
-
-===== EMAIL EPILOGUE
-
-
-===== DECISION
-
-Whereas
-
-1. The technical committee was asked to overrule the decision of the
-isdnutils maintainer to remove the creation of devices (see #698556).
-
-2. There is a tested patch ready to use available.
-
-3. The bug in question is considered release critical by the release
-team.
-
-4. In spite of being asked, the maintainer didn't comment on this
-request.
-
-5. Considering the current time plan, we don't expect to have other
-ways to create devices nodes (i.e. via kernel changes and udev) in
-time for the next stable release.
-
-
-The Technical Committee
-
-1. Decides to overrule the decision of the maintainer of isdnutils to
-remove the creation of device nodes
-
-2. Authorizes Christoph Biedl to undo the change with an upload to
-unstable earliest an week after the decision, unless the maintainer
-uploads an revert faster.
-
-3. Asks the release team to allow the fixed package to move to
-testing for the next stable release.
--- /dev/null
+* Issue http://bugs.debian.org/681783 http://bugs.debian.org/681834
+** gnome-core Depends: on network-manager which prevents network-manager from being easily replaced with wicd or similar
+** Are Depends: appropriate for metapackages
+** Is running with recommends off supported
+* Possible Solutions
+** Punt to policy
+** Ian to write up statement about Recommends
+* Open Questions
+** Appears to be general instead of specific to network-manager and the gnome metapackage
+* Proposed Resolutions
+** http://lists.debian.org/msgid-search/20514.35772.350203.926582@chiark.greenend.org.uk
+** http://lists.debian.org/msgid-search/87k3x9royz.fsf@windlord.stanford.edu
+* Adopted Resolution
+* Involved Parties
+** gnome-core@packages.debian.org, 681834@bugs.debian.org, 681783@bugs.debian.org
--- /dev/null
+wip wip wip do not use
+
+===== TITLE
+
+Dependency from gnome-core to network-manager
+
+===== WEB SUMMARY
+
+gnome-core should Recommend, not Depend, on network-manager
+(overrule maintainer).
+
+===== EMAIL INTRO
+
+The dependency from gnome-core to network-manager (via
+network-manager-gnome) was referred to the Technical Committee.
+
+The TC has made the following decision:
+
+===== DECISION
+
+Whereas:
+
+1. The gnome-core metapackage is intended to reflect the core of the
+ GNOME desktop environment: the basic tools and subsystems that
+ together constitute GNOME. The gnome metapackage is intended to
+ reflect the broader desktop environment, including extra components
+ and applications.
+
+2. network-manager is the GNOME network control system, and is
+ recommended for most GNOME users. Some Debian GNOME users don't like
+ some of network-manager's behavior and prefer to instead use other
+ tools, either basic ifupdown or other frameworks such as wicd.
+
+3. In squeeze, the gnome metapackage lists network-manager in Recommends
+ but not Depends. In wheezy, currently, network-manager has moved from
+ gnome to gnome-core, and from Recommends to Depends. This represents
+ a substantially increased insistance that users of the GNOME
+ metapackages have network-manager installed; specifically, there is no
+ longer any way to install any but the most minimal GNOME metapackage
+ (gnome-session) without installing network-manager, and users who have
+ gnome or gnome-core installed but have removed or never installed
+ network-manager will have network-manager installed during an upgrade
+ from squeeze.
+
+4. For most applications and components, the only drawback of this would
+ be some additional disk space usage, since the application, despite
+ being installed, wouldn't need to be used. However, network-manager
+ assumes that, if it is installed, it should attempt to manage the
+ system's network configuration. It attempts to avoid overriding local
+ manual configuration, but it isn't able to detect all cases where the
+ user is using some other component or system to manage networking.
+ The user has to take separate, explicit (and somewhat unusual for the
+ average user) action to disable network-manager after it has been
+ installed.
+
+5. The Technical Committee believes that this will cause undesireable
+ behavior for upgrades from squeeze, and (of somewhat lesser
+ importance) will make it more difficult than necessary for GNOME users
+ to swap network management components, something for which there
+ appears to be noticable demand. We therefore believe that
+ network-manager should be moved to Recommends in gnome-core.
+
+6. Please note that this is not a general statement about GNOME
+ components. It is very specific to network-manager because all of the
+ following apply:
+
+ (i) The package takes action automatically because it is installed,
+ rather than being a component that can either be run or not at the
+ user's choice.
+
+ (ii) The package has historically been recommended rather than listed
+ as a dependency, so existing Debian users are used to that
+ behavior and will expect it to be preserved during upgrades.
+
+ (ii) There is both demonstrable, intentional widespread replacement of
+ that package by Debian GNOME users and no significant loss of
+ unrelated GNOME desktop functionality by replacing it with a
+ different component.
+
+ If any of these points did not apply, the situation would be
+ significantly different.
+
+Therefore:
+
+7. The Technical Committee overrules the decision of the gnome-core
+ metapackage maintainers. The dependency from gnome-core to
+ network-manager-gnome should be downgraded to Recommends.
+
+8. The Technical Committee requests that the Release Managers unblock
+ the update to implement this decision, so that this change may be
+ released in wheezy.
+
+===== EMAIL EPILOGUE
+===== # processor will insert "Please see http://..." for the TC bug.
+===== # mentioning bug urls here will result in a "see also" on the web page
+
+http://bugs.debian.org/645656 (against gnome-core) will be used to
+track the the implementation of this decision.
+
+Along with the specific case of gnome-core and network-manager, the TC
+also considered the policy on use of Recommends more generally,
+particularly in the context of metapackages; this was also discussed
+and resulted in a TC decision which can be found at
+http://bugs.debian.org/681783.
--- /dev/null
+ Whereas:
+
+ 1. Our technical objectives are:
+
+ (i) Users who do not do anything special should get
+ network-manager along with gnome (in this case, along with
+ gnome-core). These users should continue to have
+ network-manager installed, across upgrades.
+
+ (ii) Users should be able to conveniently install and upgrade
+ gnome without network-manager.
+
+ (iii) Users who deliberately removed network-manager in squeeze
+ (which they will generally have done by deliberately violating
+ the Recommends from the gnome metapackage) should not have to
+ do anything special to avoid it coming back in wheezy.
+
+ (iv) Users who do make a decision that they do not want to use
+ network-manager should not have to read specific
+ documentation, or temporarily have network-manager installed,
+ risk being exposed to bugs in network-manager's configuration
+ arrangements, and so on.
+
+ 2. Our technical objectives do NOT include:
+
+ (i) The `gnome-core' metapackage should in some sense perfectly or
+ exactly correspond to GNOME upstream's definition of `the GNOME
+ Core', specifically including every such component as a hard
+ Depends.
+
+ (ii) The contents of any metapackage should be the correct
+ expression of the subjective opinion of the metapackage's
+ maintainer.
+
+ (iii) Users who choose to globally disable Recommends should still
+ get the desired behaviours as described above in point 1.
+
+ 3. The solution recommended by the gnome-core maintainers is
+ that users who do not wish to use network-manager should have it
+ installed but disable it.
+
+ Installing network-manager in these circumstances does
+ not fully meet any of the above objectives apart from 1(i).
+
+ 5. The alternative solution rejected by the gnome-core maintainers
+ is downgrade the dependency to Recommends.
+
+ This solution meets all of the objectives from point 1, except
+ that infelicities in teh package manager may mean that the user
+ in 1(iii) may need to take action to prevent network-manager
+ being reinstalled during an upgrade.
+
+ Therefore:
+
+ 6. The Technical Committee overrules the decision of the gnome-core
+ metapackage maintainer. The dependency from gnome-core to
+ network-manager-gnome should be downgraded to Recommends.
+
+ 7. The Technical Committee requests that the Release Managers
+ unblock the update to implement this decision, so that this
+ change may be released in wheezy.
--- /dev/null
+ The gnome-core metapackage is intended to reflect the core of the
+ GNOME desktop environment: the basic tools and subsystems that
+ together constitute GNOME. The gnome metapackage is intended to
+ reflect the broader desktop environment, including extra components
+ and applications.
+
+ network-manager is the GNOME network control system, and is
+ recommended for most GNOME users. Some Debian GNOME users don't like
+ some of network-manager's behavior and prefer to instead use other
+ tools, either basic ifupdown or other frameworks such as wicd.
+
+ In squeeze, the gnome metapackage lists network-manager in Recommends
+ but not Depends. In wheezy, currently, network-manager has moved from
+ gnome to gnome-core, and from Recommends to Depends. This represents
+ a substantially increased insistance that users of the GNOME
+ metapackages have network-manager installed. This change is, so far
+ as the Technical Committee understands, driven primarily by user
+ confusion and bug reports, but does not reflect a deeper or tighter
+ integration of network-manager into GNOME than was the case in
+ squeeze.
+
+ If matters are left as they currently stand, users who have the gnome
+ metapackages installed but do not have network-manager installed will,
+ in the process of upgrading from squeeze to wheezy (either due to an
+ explicit decision to remove it or an implicit decision to not install
+ it by disabling automatic installation of Recommends), end up
+ installing network-manager on systems where it is currently not
+ installed. It will also no longer be possible for users to install
+ GNOME metapackages in wheezy without installing network-manager.
+
+ For most applications and components, the only drawback of this would
+ be some additional disk space usage, since the application, despite
+ being installed, wouldn't need to be used. However, network-manager
+ assumes that, if it is installed, it should attempt to manage the
+ system's network configuration. It attempts to avoid overriding local
+ manual configuration, but it isn't able to detect all cases where the
+ user is using some other component or system to manage networking.
+ The user has to take separate, explicit (and somewhat unusual for the
+ average user) action to disable network-manager after it has been
+ installed.
+
+ The Technical Committee believes that this will cause undesireable
+ behavior for upgrades from squeeze, and (of somewhat lesser
+ importance) will make it more difficult than necessary for GNOME users
+ to swap network management components, something for which there
+ appears to be noticable demand. We therefore believe that
+ network-manager should be either moved to Recommends in gnome-core, or
+ moved from the gnome-core metapackage to the gnome metapackage (which
+ is defined as including additional, optional components).
+
+ Please note that this is not a general statement about GNOME
+ components. It is very specific to network-manager because all of the
+ following apply:
+
+ 1. The package takes action automatically because it is installed,
+ rather than being a component that can either be run or not at the
+ user's choice.
+
+ 2. The package has historically been recommended rather than listed as
+ a dependency, so existing Debian users are used to that behavior.
+
+ 3. There is both demonstrable, intentional widespread replacement of
+ that package by Debian GNOME users and no significant loss of
+ unrelated GNOME desktop functionality by replacing it with a
+ different component.
+
+ If any of these points did not apply, the situation would be
+ significantly different.
--- /dev/null
+ Whereas:
+
+ 1. The gnome-core metapackage is intended to reflect the core of the
+ GNOME desktop environment: the basic tools and subsystems that
+ together constitute GNOME. The gnome metapackage is intended to
+ reflect the broader desktop environment, including extra components
+ and applications.
+
+ 2. network-manager is the GNOME network control system, and is
+ recommended for most GNOME users. Some Debian GNOME users don't like
+ some of network-manager's behavior and prefer to instead use other
+ tools, either basic ifupdown or other frameworks such as wicd.
+
+ 3. In squeeze, the gnome metapackage lists network-manager in Recommends
+ but not Depends. In wheezy, currently, network-manager has moved from
+ gnome to gnome-core, and from Recommends to Depends. This represents
+ a substantially increased insistance that users of the GNOME
+ metapackages have network-manager installed. This change does
+ not reflect, so far as the Technical Committee understands, a
+ deeper or tighter integration of network-manager into GNOME than
+ was the case in squeeze.
+
+ 4. If matters are left as they currently stand, users who have the
+ gnome metapackages installed but do not have network-manager
+ installed (either due to an explicit decision to remove it or an
+ implicit decision to not install it by disabling automatic
+ installation of Recommends) will, in the process of upgrading from
+ squeeze to wheezy, end up installing network-manager on systems
+ where it is currently not installed. It will also no longer be
+ possible for users to install GNOME metapackages in wheezy without
+ installing network-manager.
+
+ 5. For most applications and components, the only drawback of this would
+ be some additional disk space usage, since the application, despite
+ being installed, wouldn't need to be used. However, network-manager
+ assumes that, if it is installed, it should attempt to manage the
+ system's network configuration. It attempts to avoid overriding local
+ manual configuration, but it isn't able to detect all cases where the
+ user is using some other component or system to manage networking.
+ The user has to take separate, explicit (and somewhat unusual for the
+ average user) action to disable network-manager after it has been
+ installed.
+
+ 6. The Technical Committee believes that this will cause undesireable
+ behavior for upgrades from squeeze, and (of somewhat lesser
+ importance) will make it more difficult than necessary for GNOME users
+ to swap network management components, something for which there
+ appears to be noticable demand. We therefore believe that
+ network-manager should be moved to Recommends in gnome-core.
+
+ 7. Please note that this is not a general statement about GNOME
+ components. It is very specific to network-manager because all of the
+ following apply:
+
+ (i) The package takes action automatically because it is installed,
+ rather than being a component that can either be run or not at the
+ user's choice.
+
+ (ii) The package has historically been recommended rather than listed as
+ a dependency, so existing Debian users are used to that behavior.
+
+ (ii) There is both demonstrable, intentional widespread replacement of
+ that package by Debian GNOME users and no significant loss of
+ unrelated GNOME desktop functionality by replacing it with a
+ different component.
+
+ 8. If any of these points did not apply, the situation would be
+ significantly different.
+
+ Therefore:
+
+ 9. The Technical Committee overrules the decision of the gnome-core
+ metapackage maintainers. The dependency from gnome-core to
+ network-manager-gnome should be downgraded to Recommends.
+
+ 10. The Technical Committee requests that the Release Managers
+ unblock the update to implement this decision, so that this
+ change may be released in wheezy.
--- /dev/null
+ Whereas:
+
+ 1. The gnome-core metapackage is intended to reflect the core of the
+ GNOME desktop environment: the basic tools and subsystems that
+ together constitute GNOME. The gnome metapackage is intended to
+ reflect the broader desktop environment, including extra components
+ and applications.
+
+ 2. network-manager is the GNOME network control system, and is
+ recommended for most GNOME users. Some Debian GNOME users don't like
+ some of network-manager's behavior and prefer to instead use other
+ tools, either basic ifupdown or other frameworks such as wicd.
+
+ 3. In squeeze, the gnome metapackage lists network-manager in Recommends
+ but not Depends. In wheezy, currently, network-manager has moved from
+ gnome to gnome-core, and from Recommends to Depends. This represents
+ a substantially increased insistance that users of the GNOME
+ metapackages have network-manager installed; specifically, there is no
+ longer any way to install any but the most minimal GNOME metapackage
+ (gnome-session) without installing network-manager, and users who have
+ gnome or gnome-core installed but have removed or never installed
+ network-manager will have network-manager installed during an upgrade
+ from squeeze.
+
+ 4. For most applications and components, the only drawback of this would
+ be some additional disk space usage, since the application, despite
+ being installed, wouldn't need to be used. However, network-manager
+ assumes that, if it is installed, it should attempt to manage the
+ system's network configuration. It attempts to avoid overriding local
+ manual configuration, but it isn't able to detect all cases where the
+ user is using some other component or system to manage networking.
+ The user has to take separate, explicit (and somewhat unusual for the
+ average user) action to disable network-manager after it has been
+ installed.
+
+ 5. The Technical Committee believes that this will cause undesireable
+ behavior for upgrades from squeeze, and (of somewhat lesser
+ importance) will make it more difficult than necessary for GNOME users
+ to swap network management components, something for which there
+ appears to be noticable demand. We therefore believe that
+ network-manager should be moved to Recommends in gnome-core.
+
+ 6. Please note that this is not a general statement about GNOME
+ components. It is very specific to network-manager because all of the
+ following apply:
+
+ (i) The package takes action automatically because it is installed,
+ rather than being a component that can either be run or not at the
+ user's choice.
+
+ (ii) The package has historically been recommended rather than listed
+ as a dependency, so existing Debian users are used to that
+ behavior and will expect it to be preserved during upgrades.
+
+ (ii) There is both demonstrable, intentional widespread replacement of
+ that package by Debian GNOME users and no significant loss of
+ unrelated GNOME desktop functionality by replacing it with a
+ different component.
+
+ If any of these points did not apply, the situation would be
+ significantly different.
+
+ Therefore:
+
+ 7. The Technical Committee overrules the decision of the gnome-core
+ metapackage maintainers. The dependency from gnome-core to
+ network-manager-gnome should be downgraded to Recommends.
+
+ 8. The Technical Committee requests that the Release Managers unblock
+ the update to implement this decision, so that this change may be
+ released in wheezy.
--- /dev/null
+To: debian-devel-announce@lists.debian.org
+Subject: Call for nominations for technical committee seat
+
+First and foremost, the technical committee would like to thank Manoj
+Srivastava for serving on the committee in addition to his many other
+services to Debian. With his resignation from the technical
+committee,[1] there is currently one empty seat 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.[2] 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
+October. After the selection, the committee will then recommend a
+nominee to the project leader, who may appoint the nominee (§6.2).
+
+
+1: http://lists.debian.org/msgid-search/502808CD.3090508@golden-gryphon.com
+2: See http://db.debian.org/ if you need to look the login up
--- /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 following
+nominees for agreeing to serve Debian on the Technical Committee:
+
+<<list of nominees>>
+
+The Technical Committee has begun private deliberations, and will
+recommend a nominee to the Project Leader for approval under §6.2.2.
+
+Anyone who wishes to submit information about any of the nominees
+(both praise and concerns) should e-mail
+debian-ctte-private@debian.org, and the CTTE will take the information
+into account.
+
--- /dev/null
+===== TITLE
+
+Dependency of meta-gnome on network-manager
+
+===== WEB SUMMARY
+
+The committee overrules the dependency of meta-gnome on
+network-manager while concerns raised in <a
+href="http://bugs.debian.org/681834#273">§4 of the decision in
+#681834</a> remain unaddressed.
+
+===== EMAIL INTRO
+
+The technical committee was asked in #688772 to revisit the dependency
+of gnome metapackages on network-manager. The decision is below:
+
+===== EMAIL EPILOGUE
+
+The committee would like to thank Michael Biebl for discussing the
+concerns of the technical committee and working to address those
+concerns through technical changes to NM.
+
+===== DECISION
+
+1. The TC notes the decision of the meta-gnome maintainers to
+ implement the TC decision in #681834 by:
+ (a) softening the dependency in the gnome-core metapackage
+ from Depends to Recommends, as required
+ (b) adding a new dependency in the gnome metapackage,
+ as a Depends. (In squeeze, this is where the dependency
+ was, but it was a Recommends.)
+
+2. Our intent, as stated in the rationale section of our previous
+ decision (#681834, paras 3 and 5), is that squeeze users who have
+ gnome installed but not network-manager do not find that
+ network-manager becomes installed when they upgrade to wheezy.
+
+3. A Recommends from gnome to network-manager-gnome would serve no
+ purpose in wheezy as gnome Depends on gnome-core which already
+ Recommends network-manager-gnome.
+
+Therefore
+
+4. We overrule the decision of the meta-gnome maintainers to add a
+ dependency from gnome to network-manager-gnome; this dependency
+ should be removed. If in the opinion of the NM maintainer (and
+ before the release of wheezy the Chair of the Technical Committee
+ or an individual delegated by the Chair in consultation with the
+ Release Team) the concerns raised in §4 of the CTTE decision
+ #681834 have been addressed through technical means (e.g. by
+ preventing the starting of NM as discussed in #688772), the
+ meta-gnome maintainers may freely adjust the dependencies as
+ usual.
+
+ Specifically, valid bugs where existing valid network
+ configurations are broken by the automatic, required installation
+ on system upgrade of packages not previously installed which
+ perform network configuration on should have severity serious.
+
+5. We request that the Release Team unblock update(s) to meta-gnome so
+ that our decisions may be implemented in wheezy.
+
+6. We request that a release note is created explaining that gnome
+ users who do not currently have NM installed consider installing
+ it.
--- /dev/null
+1. The TC notes the decision of the meta-gnome maintainers to
+ implement the TC decision in #681834 by:
+ (a) softening the dependency in the gnome-core metapackage
+ from Depends to Recommends, as required
+ (b) adding a new dependency in the gnome metapackage,
+ as a Depends. (In squeeze, this is where the dependency
+ was, but it was a Recommends.)
+
+2. Our intent, as stated in the rationale section of our previous
+ decision (#681834, paras 3 and 5), is that squeeze users who have
+ gnome installed but not network-manager do not find that
+ network-manager becomes installed when they upgrade to wheezy.
+
+3. A Recommends from gnome to network-manager-gnome would serve no
+ purpose in wheezy as gnome Depends on gnome-core which already
+ Recommends network-manager-gnome.
+
+Therefore
+
+A 4. We overrule the decision of the meta-gnome maintainers to add a
+A dependency from gnome to network-manager-gnome; this dependency
+A should be removed for the release of wheezy.
+A
+A 5. We request that the Release Team unblock update(s) to meta-gnome so
+A that our decisions may be implemented in wheezy.
+A
+A 6. We request that a release note is created explaining that gnome
+A users who do not currently have NM installed consider installing
+A it.
+
+
+B 4. We overrule the decision of the meta-gnome maintainers to add a
+B dependency from gnome to network-manager-gnome; this dependency
+B should be removed. If in the opinion of the NM maintainer (and
+B before the release of wheezy the Chair of the Technical Committee
+B or an individual delegated by the Chair in consultation with the
+B Release Team) the concerns raised in §4 of the CTTE decision
+B #681834 have been addressed through technical means (e.g. by
+B preventing the starting of NM as discussed in #688772), the
+B meta-gnome maintainers may freely adjust the dependencies as
+B usual.
+B
+B Specifically, valid bugs where existing valid network
+B configurations are broken by the automatic, required installation
+B on system upgrade of packages not previously installed which
+B perform network configuration on should have severity serious.
+B
+B 5. We request that the Release Team unblock update(s) to meta-gnome so
+B that our decisions may be implemented in wheezy.
+B
+B 6. We request that a release note is created explaining that gnome
+B users who do not currently have NM installed consider installing
+B it.
+
+C 4. After further discussion, we understand that reintroducing
+C network-manager on upgrade was part of the intent, due to both
+C substantial improvements in network-manager and tighter integration of
+C network-manager with the GNOME desktop in wheezy. Since the gnome
+C metapackage has historically been more aggressive at pulling in
+C additional packages, we believe the move of the dependency from
+C gnome-core to gnome is an acceptable compromise that was not raised
+C during the previous discussion. Users who want to remove
+C network-manager can still use the gnome-core metapackage to get the
+C basic GNOME desktop functionality.
+C
+C We recommend that this upgrade behavior for users of the gnome
+C metapackage be documented in the release notes.
--- /dev/null
+Whereas
+
+1. The TC notes the decision of the meta-gnome maintainers to
+ implement our decision in #681834 by:
+ (a) softening the dependency in the gnome-core metapackage
+ from Depends to Recommends, as required
+ (b) adding a new dependency in the gnome metapackage,
+ as a Depends. (In squeeze, this is where the dependency
+ was, but it was a Recommends.)
+
+2. Our intent, as stated in the rationale section of our previous
+ decision (#681834, paras 3 and 5), is that squeeze users who have
+ gnome installed but not network-manager do not find that
+ network-manager becomes installed when they upgrade to wheezy.
+
+3. The actions of the meta-gnome maintainers do not achieve this
+ objective.
+
+4. Insofar as any reasons have been advanced for the meta-gnome
+ maintainer's decision, we do not find them convincing.
+
+5. A Recommends from gnome to network-manager-gnome would serve no
+ purpose in wheezy as gnome Depends on gnome-core which already
+ Recommends network-manager-gnome.
+
+Therefore
+
+6. We overrule the decision of the meta-gnome maintainers to add a
+ dependency from gnome to network-manager-gnome. This dependency
+ should be removed.
+
+7. We request that the Release Team unblock update(s) to meta-gnome so
+ that our decisions may be implemented in wheezy.
+
+8. We specifically forbid anyone from introducing in wheezy, or
+ in sid until wheezy is released:
+ a. Any new or enhanced dependencies, or any other mechanisms,
+ which increase the likelihood of network-manager being
+ installed;
+ b. Any new or enhanced user-facing warnings, imprecations, or
+ other kinds of message regarding the alleged desirability or
+ requirement to install network-manager;
+ c. Any change which in any way impairs (or further impairs) the
+ functioning of systems with GNOME components installed but
+ without network-manager;
+ d. Any change which is contrary to the spirit or intent of either
+ our previous resolution in #681834 or this resolution.
+ without first obtaining the permission of at least one member of
+ the Technical Committee.
+
+Furthermore
+
+9. It is disappointing that this proposed solution to the problem was
+ not mentioned during the TC discussion. If it had been, it could
+ have been accepted or rejected by the TC at the time.
+
+10. We remind everyone that the Constitution requires members of the
+ project not to work against decisions properly made according to
+ the project's governance processes. On this occasion we do not
+ feel it necessary to refer anyone to the Debian Account Managers
+ asking for a review of their status.
--- /dev/null
+===== TITLE
+
+Creation of isdn devices by isdnutils
+
+===== WEB SUMMARY
+
+The committee overrules the maintainer of isdnutils to require the
+inclusion of code to create isdn devices by isdnutils.
+
+===== EMAIL INTRO
+
+The technical committee was asked in #698556 to overrule the decision
+of the isdnutils maintainer to remove the creation of devices.
+
+===== EMAIL EPILOGUE
+
+
+===== DECISION
+
+Whereas
+
+1. The technical committee was asked to overrule the decision of the
+isdnutils maintainer to remove the creation of devices (see #698556).
+
+2. There is a tested patch ready to use available.
+
+3. The bug in question is considered release critical by the release
+team.
+
+4. In spite of being asked, the maintainer didn't comment on this
+request.
+
+5. Considering the current time plan, we don't expect to have other
+ways to create devices nodes (i.e. via kernel changes and udev) in
+time for the next stable release.
+
+
+The Technical Committee
+
+1. Decides to overrule the decision of the maintainer of isdnutils to
+remove the creation of device nodes
+
+2. Authorizes Christoph Biedl to undo the change with an upload to
+unstable earliest an week after the decision, unless the maintainer
+uploads an revert faster.
+
+3. Asks the release team to allow the fixed package to move to
+testing for the next stable release.
projects / debian-ctte.git / commitdiff