diff -Nru doc-debian-4.0.2ubuntu1/debian/changelog doc-debian-6.1ubuntu1/debian/changelog --- doc-debian-4.0.2ubuntu1/debian/changelog 2010-02-10 17:39:42.000000000 +0000 +++ doc-debian-6.1ubuntu1/debian/changelog 2012-12-05 19:14:29.000000000 +0000 @@ -1,3 +1,36 @@ +doc-debian (6.1ubuntu1) raring; urgency=low + + * Merge from Debian unstable. (LP: #1086940) Remaining changes: + - /doc mailing-lists.txt added + - /doc/Makefile edited to build regadrsless mailing-lists.wml existence + + -- Alessandro Losavio Wed, 05 Dec 2012 18:35:32 +0000 + +doc-debian (6.1) unstable; urgency=low + + * Update the contents to the latest available at the website + * Simplify debian/rules using CDBS + - Use standard build process. This build now ensures that we provide + a md5sums file (Closes: #672319) + - Text files are now compressed + - Some Lintian bugs now go away + * debian/control: Add provided Build-Depends + * Include the wml sources in the package to make it easier to build the + sources when a copy of the website is not available (Closes: #690791) + * debian/control: Updated Standards version, no changes needed. + + -- Javier Fernández-Sanguino Peña Wed, 17 Oct 2012 23:25:00 +0200 + +doc-debian (6.0) unstable; urgency=low + + * Update the contents to the latest available at the website + * Remove Pierre Machard as Uploader (Closes: 576557) + * doc/source-unpack.txt: Apply patch provided by Colin Watson to improve + the document. This patch documents all formats currently in use in the + Debian archive. (Closes: #579263) + + -- Javier Fernández-Sanguino Peña Sat, 14 Apr 2012 12:08:29 +0200 + doc-debian (4.0.2ubuntu1) lucid; urgency=low * Merge from debian testing. Remaining changes: LP: #517978 @@ -18,10 +51,12 @@ the website. - Include the version 1.3 of the constitution - Updated bug-reporting.txt which nows describes - X-Debbugs-CC (Closes: #298991) + X-Debbugs-CC (Closes: #298991, #367602) - Updated bug-maint-mailcontrol.txt which now describes the 'unarchive' option (Closes: 489517) - Update the constitution version to 1.4 (Closes: #520684, #367787) + - Update bug-maint-mailcontrol.txt which now describes + the possibility of forwarding to URLs (Closes: #457715) * Fix doc/Makefile so that the social contract file is not overwritten with version 1.0 (Closes: #512251) * Modify doc/Makefile so that the constitution.wml file is changed @@ -79,6 +114,8 @@ - describe how to install a developer's environment - fix location of mirror list - init handles runlevels, not the kernel (Closes: #416203) + - 'bug-reporting' now describes nnn-quiet (Closes: #367548) + - typo fixes in consitution.txt (Closes: #367787) * Update to the latest contents of the www pages (bugs and constitution) - fix a typo in the constitution (Closes: #367787) @@ -453,7 +490,7 @@ version at /usr/share/doc/debian/mailing-lists.txt for now (Bug #59136). -- Santiago Vila Thu, 2 Mar 2000 16:57:39 +0100 - + doc-debian (2.1) frozen unstable; urgency=low * Removed outdated information about the kernel-source packages (Bug #33469). @@ -464,14 +501,14 @@ * Standards-Version: 3.1.1. -- Santiago Vila Sat, 5 Feb 2000 18:49:15 +0100 - + doc-debian (2.0.1) unstable; urgency=low * Refreshed doc directory from ftp.debian.org. * Updated figures about disk space for mirroring. -- Santiago Vila Fri, 12 Nov 1999 13:14:50 +0100 - + doc-debian (2.0.0) unstable; urgency=low * Updated information about make-kpkg (Bug #38106). @@ -640,24 +677,14 @@ -- Sven Rudolph Thu, 26 Sep 1996 22:09:30 +0200 Mon Aug 26 21:05:52 1996 Sven Rudolph - * FAQ and other files updated - Fri Jun 14 02:19:07 1996 Sven Rudolph - * releasing 1.0-3 - * FAQ updated - Thu Mar 14 xx:xx:xx 1996 Sven Rudolph - * gzipping all files - * debian.control: added Architecture field - * debian.control: formatted Description - Wed Feb 21 22:53:06 1996 Sven Rudolph - * added Debian GNU/Linux package maintenance system files diff -Nru doc-debian-4.0.2ubuntu1/debian/control doc-debian-6.1ubuntu1/debian/control --- doc-debian-4.0.2ubuntu1/debian/control 2010-02-10 17:39:42.000000000 +0000 +++ doc-debian-6.1ubuntu1/debian/control 2012-12-05 18:34:11.000000000 +0000 @@ -3,8 +3,9 @@ Priority: standard Maintainer: Ubuntu Developers XSBC-Original-Maintainer: Javier Fernandez-Sanguino Pen~a -Uploaders: Pierre Machard , Josip Rodin -Standards-Version: 3.8.0 +Uploaders: Josip Rodin +Standards-Version: 3.9.3 +Build-Depends-Indep: debhelper (>= 8.0.0), cdbs, wml, lynx Vcs-Browser: http://svn.debian.org/wsvn/ddp/packages/trunk/doc-debian/ Vcs-Svn: svn://svn.debian.org/ddp/packages/trunk/doc-debian/ diff -Nru doc-debian-4.0.2ubuntu1/debian/doc-debian.doc-base.debian-constitution-text doc-debian-6.1ubuntu1/debian/doc-debian.doc-base.debian-constitution-text --- doc-debian-4.0.2ubuntu1/debian/doc-debian.doc-base.debian-constitution-text 1970-01-01 01:00:00.000000000 +0100 +++ doc-debian-6.1ubuntu1/debian/doc-debian.doc-base.debian-constitution-text 2012-10-17 23:36:05.000000000 +0100 @@ -0,0 +1,12 @@ +Document: debian-constitution-text +Title: Debian Constitution +Author: The Debian Project +Abstract: This document contains the complete text of Debian Project + Constitution (v1.3), in text format. Version 1.3 ratified on + September 24th, 2006. Supersedes version 1.2 ratified on October + 29th, 2003. Supersedes Version 1.1 ratified on June 21st, 2003, + which itself supersedes Version 1.0 ratified on December 2nd, 1998 +Section: Debian + +Format: text +Files: /usr/share/doc/debian/constitution.txt.gz diff -Nru doc-debian-4.0.2ubuntu1/debian/doc-debian.doc-base.debian-mailing-lists doc-debian-6.1ubuntu1/debian/doc-debian.doc-base.debian-mailing-lists --- doc-debian-4.0.2ubuntu1/debian/doc-debian.doc-base.debian-mailing-lists 1970-01-01 01:00:00.000000000 +0100 +++ doc-debian-6.1ubuntu1/debian/doc-debian.doc-base.debian-mailing-lists 2012-10-17 23:34:16.000000000 +0100 @@ -0,0 +1,8 @@ +Document: debian-mailing-lists +Title: Debian mailing lists +Author: Debian Listmasters +Abstract: A comprehensive list of all mailing lists at lists.debian.org +Section: Debian + +Format: text +Files: /usr/share/doc/debian/mailing-lists.txt.gz diff -Nru doc-debian-4.0.2ubuntu1/debian/doc-debian.doc-base.debian-manifesto doc-debian-6.1ubuntu1/debian/doc-debian.doc-base.debian-manifesto --- doc-debian-4.0.2ubuntu1/debian/doc-debian.doc-base.debian-manifesto 1970-01-01 01:00:00.000000000 +0100 +++ doc-debian-6.1ubuntu1/debian/doc-debian.doc-base.debian-manifesto 2012-10-17 23:46:28.000000000 +0100 @@ -0,0 +1,12 @@ +Document: debian-manifesto +Title: The Debian Linux Manifesto +Author: Ian A. Murdock +Abstract: The Debian Manifesto was released in 1993 by Ian Murdock. The document + outlines his view for a brand new Linux distribution which would be developed + openly, describes why the world needed this distribution and which problems + would the distribution solved. This document is provided in order to document + Debian's history. +Section: Debian + +Format: text +Files: /usr/share/doc/debian/debian-manifesto.gz diff -Nru doc-debian-4.0.2ubuntu1/debian/doc-debian.doc-base.debian-reporting-bugs doc-debian-6.1ubuntu1/debian/doc-debian.doc-base.debian-reporting-bugs --- doc-debian-4.0.2ubuntu1/debian/doc-debian.doc-base.debian-reporting-bugs 1970-01-01 01:00:00.000000000 +0100 +++ doc-debian-6.1ubuntu1/debian/doc-debian.doc-base.debian-reporting-bugs 2012-10-17 23:36:15.000000000 +0100 @@ -0,0 +1,8 @@ +Document: debian-reporting-bugs +Title: How to report a bug in Debian +Author: Ian Jackson, Steven Brenner and Darren Benham +Abstract: Description on how to properly report a bug in Debian GNU/Linux. +Section: Debian + +Format: text +Files: /usr/share/doc/debian/bug-reporting.txt.gz diff -Nru doc-debian-4.0.2ubuntu1/debian/doc-debian.doc-base.debian-social-contract doc-debian-6.1ubuntu1/debian/doc-debian.doc-base.debian-social-contract --- doc-debian-4.0.2ubuntu1/debian/doc-debian.doc-base.debian-social-contract 1970-01-01 01:00:00.000000000 +0100 +++ doc-debian-6.1ubuntu1/debian/doc-debian.doc-base.debian-social-contract 2012-10-17 23:37:15.000000000 +0100 @@ -0,0 +1,12 @@ +Document: debian-social-contract +Title: The Debian Social Contract, and the Debian Free Software Guidelines +Author: The Debian Project +Abstract: This is the "social contract" (v1.1) we offer to the free software + community. The Debian Free Software Guidelines (DFGS) are the set of + license conditions to be met for packages to be part of the Debian system. + The version 1.1 ratified on April 26, 2004. This version supersedes version + 1.0, ratified on April 5, 1997. +Section: Debian + +Format: text +Files: /usr/share/doc/debian/social-contract.txt.gz diff -Nru doc-debian-4.0.2ubuntu1/debian/doc-debian.install doc-debian-6.1ubuntu1/debian/doc-debian.install --- doc-debian-4.0.2ubuntu1/debian/doc-debian.install 1970-01-01 01:00:00.000000000 +0100 +++ doc-debian-6.1ubuntu1/debian/doc-debian.install 2012-10-17 23:40:51.000000000 +0100 @@ -0,0 +1,2 @@ +doc/*.txt usr/share/doc/debian +doc/debian-manifesto usr/share/doc/debian diff -Nru doc-debian-4.0.2ubuntu1/debian/rules doc-debian-6.1ubuntu1/debian/rules --- doc-debian-4.0.2ubuntu1/debian/rules 2010-02-10 17:39:42.000000000 +0000 +++ doc-debian-6.1ubuntu1/debian/rules 2012-12-05 18:33:18.000000000 +0000 @@ -1,48 +1,38 @@ #!/usr/bin/make -f # derived from sample debian/rules file for GNU hello by Ian Jackson. -tmp = $(CURDIR)/debian/tmp -docdir = $(tmp)/usr/share/doc/debian +# Set this to enable debugging +export DH_VERBOSE = 1 -build: stamp-build -stamp-build: - test -f debian/rules - touch $@ - -clean: - test -f debian/rules - test "`id -u`" -eq 0 - rm -rf $(tmp) - rm -f stamp-build debian/files `find . -name "*~"` +include /usr/share/cdbs/1/rules/debhelper.mk -refresh: +build/doc-debian:: cd doc && $(MAKE) -binary: binary-indep binary-arch +clean:: + cd doc && $(MAKE) clean -binary-arch: +get-orig-source:: + cd doc && $(MAKE) update -binary-indep: build - test -f debian/rules - test "`id -u`" -eq 0 - rm -rf $(tmp) - - install -m 755 -d $(tmp)/DEBIAN \ - $(tmp)/usr/share/doc-base $(tmp)/usr/share/doc/doc-debian $(docdir) -# Copy all the contents of doc/ - cp -p doc/* $(docdir) -# Save for the files that are used to auto-generate them - rm -f $(docdir)/*wml - rm -f $(docdir)/Makefile - - install -m 755 debian/prerm debian/postinst $(tmp)/DEBIAN - install -m 644 doc-base/* $(tmp)/usr/share/doc-base - install -m 644 debian/copyright $(tmp)/usr/share/doc/doc-debian - gzip -c9 debian/changelog > $(tmp)/usr/share/doc/doc-debian/changelog.gz - chown -R root.root $(tmp) && chmod -R go=rX $(tmp) - dpkg-gencontrol -isp - dpkg --build $(tmp) .. - - - -.PHONY: build clean binary binary-arch binary-indep +#install:: +# TODO - move the files +# cp $(docdir)/constitution.1.3.txt ../constitution.txt +# cp $(docdir)/social-contract.txt ../social-contract.txt + +binary-indep/doc-debian:: + dpkg-distaddfile constitution.txt byhand - + dpkg-distaddfile social-contract.txt byhand - +# Code disabled: There already is a mechanism (which one?) +# synching files over to f.d.o/debian/doc although not exactly the +# same (it retains page footers, which this one doesn't) +# +# cp $(docdir)/debian-manifesto ../ +# dpkg-distaddfile debian-manifesto byhand - +# ( cd $(docdir) && ls *.txt) | \ +# grep -v constitution | \ +# grep -v social-contract | \ +# while read txtfile; do \ +# cp $(docdir)/$$txtfile ../ ; \ +# dpkg-distaddfile $$txtfile byhand - ; \ +# done diff -Nru doc-debian-4.0.2ubuntu1/doc/bug-log-access.txt doc-debian-6.1ubuntu1/doc/bug-log-access.txt --- doc-debian-4.0.2ubuntu1/doc/bug-log-access.txt 2010-01-11 21:03:52.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/bug-log-access.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,46 +0,0 @@ - Methods of accessing the bug tracking system logs - -Accessing active bug reports - - Each message received at or sent by the bug processing system is logged - and made available in a number of ways. - - The primary access method is to use the web pages. See the forms on the - main BTS page at http://bugs.debian.org/ - - There is a mailserver which can send bug reports as plain text on - request. To use it send the word help as the sole contents of an email - to request@bugs.debian.org (the Subject of the message is ignored), or - read the instructions on the World Wide Web or in the file - bug-log-mailserver.txt. - -Accessing archived bug reports - - Each closed bug report is archived 28 days after the last message - relating to it is received and filed. This means that it is no longer - possible to access it or change anything about it using the control and - service bots. However, the reports are still accessible for viewing. - - You can search the bug report archive using the WWW forms at - http://bugs.debian.org/, simply select the "archived bugs" option. - - Note that it doesn't contain the oldest closed bug reports, only those - after #40000, approximately. - -Accessing the raw bug data - - If you need to get hold of the raw data used by the bug tracking - system, you can mirror it using rsync from bugs-mirror.debian.org. The - relevant modules are bts-spool-db (for the active bug spool), - bts-spool-archive (for bugs that have been closed for a while and thus - archived), and bts-spool-index (for the bug index files). - - At the time of writing, the active spool is about 2.5GB and the - archived spool is about 10GB. If you only need a sample for testing - purposes, please consider downloading only part of the active spool - rather than the whole thing. - - Please do not rely on *.status files in the bug spools, as they are - obsolete, for compatibility purposes only, and will be removed at some - point in the future. Use the *.summary files instead. - __________________________________________________________________ diff -Nru doc-debian-4.0.2ubuntu1/doc/bug-log-mailserver.txt doc-debian-6.1ubuntu1/doc/bug-log-mailserver.txt --- doc-debian-4.0.2ubuntu1/doc/bug-log-mailserver.txt 2010-01-11 21:03:53.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/bug-log-mailserver.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,131 +0,0 @@ - Introduction to the bug system request server - - There is a mailserver which can send the bug reports and indices as - plain text on request. - - To use it you send a mail message to request@bugs.debian.org. The - Subject of the message is ignored, except for generating the Subject of - the reply. - - The body you send should be a series of commands, one per line. You'll - receive a reply which looks like a transcript of your message being - interpreted, with a response to each command. No notifications are sent - to anyone for the commands listed here and the mail isn't logged - anywhere publicly available. - - Any text on a line starting with a hash sign # is ignored; the server - will stop processing when it finds a line with a control terminator ( - quit, thank you, or two hyphens are common examples). It will also stop - if it encounters too many unrecognised or badly-formatted commands. If - no commands are successfully handled it will send the help text for the - server. - - Commands available - - send bugnumber - send-detail bugnumber - Requests the transcript for the bug report in question. - send-detail sends all of the "boring" messages in the transcript - as well, such as the various auto-acks. - - index [full] - index-summary by-package - index-summary by-number - Request the full index (with full details, and including done - and forwarded reports), or the summary sorted by package or by - number, respectively. - - index-maint - Requests the index page giving the list of maintainers with bugs - (open and recently-closed) in the tracking system. - - index maint maintainer - Requests the index pages of bugs in the system for the - maintainer maintainer. The search term is an exact match. The - bug index will be sent in a separate message. - - index-packages - Requests the index page giving the list of packages with bugs - (open and recently-closed) in the tracking system. - - index packages package - Requests the index pages of bugs in the system for the package - package. The search term is an exact match. The bug index will - be sent in a separate message. - - send-unmatched [this|0] - send-unmatched last|-1 - send-unmatched old|-2 - Requests logs of messages not matched to a particular bug - report, for this week, last week and the week before. (Each week - ends on a Wednesday.) - - getinfo filename - Request a file containing information about package(s) and or - maintainer(s) - the files available are: - - maintainers - The unified list of packages' maintainers, as used by the - tracking system. This is derived from information in the - Packages files, override files and pseudo-packages files. - - override.distribution - override.distribution.non-free - override.distribution.contrib - override.experimental - Information about the priorities and sections of packages - and overriding values for the maintainers. This - information is used by the process which generates the - Packages files in the FTP archive. Information is - available for each of the main distribution trees - available, by their codewords. - - pseudo-packages.description - pseudo-packages.maintainers - List of descriptions and maintainers respectively for - pseudo-packages. - - refcard - Requests that the mailservers' reference card be sent in plain - ASCII. - - help - Requests that this help document be sent by email in plain - ASCII. - - quit - stop - thank - thanks - thankyou - thank you - -- - Stops processing at this point of the message. After this you - may include any text you like, and it will be ignored. You can - use this to include longer comments than are suitable for #, for - example for the benefit of human readers of your message - (reading it via the tracking system logs or due to a CC or BCC). - - #... - One-line comment. The # must be at the start of the line. - - debug level - Sets the debugging level to level, which should be a nonnegative - integer. 0 is no debugging; 1 is usually sufficient. The - debugging output appears in the transcript. It is not likely to - be useful to general users of the bug system. - - There is a reference card for the mailservers, available via the WWW, - in bug-mailserver-refcard.txt or by email using the refcard command - (see above). - - If you wish to manipulate bug reports you should use the - control@bugs.debian.org address, which understands a superset of the - commands listed above. This is described in another document, available - on the WWW, in the file bug-maint-mailcontrol.txt, or by sending help - to control@bugs. - - In case you are reading this as a plain text file or via email: an HTML - version is available via the bug system main contents page - http://www.debian.org/Bugs/. - __________________________________________________________________ diff -Nru doc-debian-4.0.2ubuntu1/doc/bug-mailserver-refcard.txt doc-debian-6.1ubuntu1/doc/bug-mailserver-refcard.txt --- doc-debian-4.0.2ubuntu1/doc/bug-mailserver-refcard.txt 2010-01-11 21:03:54.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/bug-mailserver-refcard.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,73 +0,0 @@ - Mail servers' reference card - - Full documentation of the mail servers is available on the WWW, in the - files bug-log-mailserver.txt and bug-maint-mailcontrol.txt or by - sending the word help to each mailserver. - -Synopsis of commands available at request@bugs.debian.org - - * send bugnumber - * send-detail bugnumber - * index [full] - * index-summary by-package - * index-summary by-number - * index-maint - * index maint maintainer - * index-packages - * index packages package - * send-unmatched [this|0] - * send-unmatched last|-1 - * send-unmatched old|-2 - * getinfo filename (ftp.debian.org/debian/doc/*) - * help - * refcard - * quit|stop|thank...|--... - * #... (comment) - * debug level - -Synopsis of extra commands available at control@bugs.debian.org - - * reassign bugnumber package [ version ] - * severity bugnumber severity - * reopen bugnumber [ originator-address | = | ! ] - * found bugnumber [ version ] - * notfound bugnumber version - * submitter bugnumber originator-address | ! - * forwarded bugnumber address - * notforwarded bugnumber - * owner bugnumber address | ! - * noowner bugnumber - * retitle bugnumber new-title - * clone bugnumber NewID [ new IDs ... ] - * merge bugnumber bugnumber ... - * unmerge bugnumber - * forcemerge bugnumber bugnumber ... - * tag bugnumber [ + | - | = ] tag [ tag ... ] - * block bugnumber by bug ... - * unblock bugnumber by bug ... - * close bugnumber [ fixed-version ] (deprecated -- you must - separately tell originator why, see "Closing bug reports" instead) - - reopen with = or no originator address leaves the originator as the - original submitter; ! sets it to you, the person doing the reopen. - - Severities are critical, grave, serious, important, normal, minor, and - wishlist. - - Tags currently include patch, wontfix, moreinfo, unreproducible, help, - pending, fixed, security, upstream, confirmed, fixed-upstream, - fixed-in-experimental, d-i, ipv6, lfs, l10n, potato, woody, sarge, - sarge-ignore, etch, etch-ignore, sid, and experimental. - -Synopsis of bug submission and followup addresses - - * nnn[ -submit | ] - * nnn-maintonly - * nnn-quiet - * nnn-forwarded - * nnn-request - * nnn-submitter - * nnn-done - * nnn-close - * nnn-subscribe - __________________________________________________________________ diff -Nru doc-debian-4.0.2ubuntu1/doc/bug-mailserver-refcard.wml doc-debian-6.1ubuntu1/doc/bug-mailserver-refcard.wml --- doc-debian-4.0.2ubuntu1/doc/bug-mailserver-refcard.wml 2010-01-11 21:03:53.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/bug-mailserver-refcard.wml 2012-10-20 04:09:43.000000000 +0100 @@ -25,7 +25,7 @@
  • getinfo filename (ftp.debian.org/debian/doc/*)
  • help
  • refcard
    • -
  • quit|stop|thank...|--...
    • +
  • thanks
  • #... (comment)
  • debug level
    • @@ -66,19 +66,9 @@ the originator as the original submitter; ! sets it to you, the person doing the reopen.

    -

    Severities are critical, -grave, serious, important, -normal, minor, and wishlist.

    - -

    Tags currently include patch, -wontfix, moreinfo, unreproducible, -help, pending, fixed, -security, upstream, confirmed, -fixed-upstream, fixed-in-experimental, d-i, ipv6, -lfs, l10n, potato, -woody, sarge, sarge-ignore, -etch, etch-ignore, sid, and -experimental.

    +

    Severities are .

    + +

    Tags currently include .

    Synopsis of bug submission and followup addresses

    diff -Nru doc-debian-4.0.2ubuntu1/doc/bug-maint-info.txt doc-debian-6.1ubuntu1/doc/bug-maint-info.txt --- doc-debian-4.0.2ubuntu1/doc/bug-maint-info.txt 2010-01-11 21:06:49.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/bug-maint-info.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,434 +0,0 @@ -Information regarding the bug processing system for package maintainers and bug - triagers - - Initially, a bug report is submitted by a user as an ordinary mail - message to submit@bugs.debian.org. This will then be given a number, - acknowledged to the user, and forwarded to debian-bugs-dist. If the - submitter included a Package line listing a package with a known - maintainer the maintainer will get a copy too. - - The Subject line will have Bug#nnn: added, and the Reply-To will be set - to include both the submitter of the report and nnn@bugs.debian.org. - * Closing bug reports - * Followup messages - * Severity levels - * Tags for bug reports - * Recording that you have passed on a bug report - * Changing bug ownership - * Incorrectly listed package maintainers - * Reopening, reassigning and manipulating bugs - * Subscribing to bugs - * More-or-less obsolete subject-scanning feature - * Obsolete X-Debian-PR: quiet feature - -Closing bug reports - - Debian bug reports should be closed when the problem is fixed. Problems - in packages can only be considered fixed once a package that includes - the bug fix enters the Debian archive. - - Normally, the only people that should close a bug report are the - submitter of the bug and the maintainer(s) of the package against which - the bug is filed. There are exceptions to this rule, for example, the - bugs filed against unknown packages or certain generic pseudo-packages. - When in doubt, don't close bugs, first ask for advice on the - debian-devel mailing list. - - Bug reports should be closed by sending email to - nnn-done@bugs.debian.org. The message body needs to contain an - explanation of how the bug was fixed. - - With the emails received from the bug tracking system, all you need to - do to close the bug is to make a Reply in your mail reader program and - edit the To field to say nnn-done@bugs.debian.org instead of - nnn@bugs.debian.org (nnn-close is provided as an alias for nnn-done). - - Where applicable, please supply a Version line in the pseudo-header of - your message when closing a bug, so that the bug tracking system knows - which releases of the package contain the fix. - - The person closing the bug, the person who submitted it and the - debian-bugs-closed mailing list will each get a notification about the - change in status of the report. The submitter and the mailing list will - also receive the contents of the message sent to nnn-done. - -Followup messages - - The bug tracking system will include the submitter's address and the - bug address (nnn@bugs.debian.org) in the Reply-To header after - forwarding the bug report. Please note that these are two distinct - addresses. - - If a developer wishes to reply to a bug report they should simply reply - to the message, respecting the Reply-To header. This will not close the - bug. - - The bug tracking system will receive the message at - nnn@bugs.debian.org, pass it on to the package maintainer, file the - reply with the rest of the logs for that bug report and forward it to - debian-bugs-dist. - - Sending a message to nnn-submitter@bugs.debian.org will explicitly - email the submitter of the bug and place a copy in the Bug tracking - system. The message will not be sent to package maintainer. - - If you wish to send a followup message which is not appropriate for - debian-bugs-dist you can do so by sending it to - nnn-quiet@bugs.debian.org or nnn-maintonly@bugs.debian.org. Mail to - nnn-quiet@bugs.debian.org is filed in the Bug Tracking System but is - not delivered to any individuals or mailing lists. Mail to - nnn-maintonly@bugs.debian.org is filed in the Bug Tracking System and - is delivered only to the maintainer of the package in question. - - Do not use the "reply to all recipients" or "followup" feature of your - mailer unless you intend to edit down the recipients substantially. In - particular, see that you don't send followup messages to - submit@bugs.debian.org. - - For more information about headers to suppress ACK messages and how to - send carbon copies using the Bug Tracking System, see the instructions - for reporting bugs. - -Severity levels - - The bug system records a severity level with each bug report. This is - set to normal by default, but can be overridden either by supplying a - Severity line in the pseudo-header when the bug is submitted (see the - instructions for reporting bugs), or by using the severity command with - the control request server. - - The severity levels are: - - critical - makes unrelated software on the system (or the whole system) - break, or causes serious data loss, or introduces a security - hole on systems where you install the package. - - grave - makes the package in question unusable or mostly so, or causes - data loss, or introduces a security hole allowing access to the - accounts of users who use the package. - - serious - is a severe violation of Debian policy (roughly, it violates a - "must" or "required" directive), or, in the package maintainer's - or release manager's opinion, makes the package unsuitable for - release. - - important - a bug which has a major effect on the usability of a package, - without rendering it completely unusable to everyone. - - normal - the default value, applicable to most bugs. - - minor - a problem which doesn't affect the package's usefulness, and is - presumably trivial to fix. - - wishlist - for any feature request, and also for any bugs that are very - difficult to fix due to major design considerations. - - Certain severities are considered release-critical, meaning the bug - will have an impact on releasing the package with the stable release of - Debian. Currently, these are critical, grave and serious. For complete - and canonical rules on what issues merit these severities, see the list - of Release-Critical Issues for Lenny. - -Tags for bug reports - - Each bug can have zero or more of a set of given tags. These tags are - displayed in the list of bugs when you look at a package's page, and - when you look at the full bug log. - - Tags can be set by supplying a Tags line in the pseudo-header when the - bug is submitted (see the instructions for reporting bugs), or by using - the tags command with the control request server. Separate multiple - tags with commas, spaces, or both. - - The current bug tags are: - - patch - A patch or some other easy procedure for fixing the bug is - included in the bug logs. If there's a patch, but it doesn't - resolve the bug adequately or causes some other problems, this - tag should not be used. - - wontfix - This bug won't be fixed. Possibly because this is a choice - between two arbitrary ways of doing things and the maintainer - and submitter prefer different ways of doing things, possibly - because changing the behaviour will cause other, worse, problems - for others, or possibly for other reasons. - - moreinfo - This bug can't be addressed until more information is provided - by the submitter. The bug will be closed if the submitter - doesn't provide more information in a reasonable (few months) - timeframe. This is for bugs like "It doesn't work". What doesn't - work? - - unreproducible - This bug can't be reproduced on the maintainer's system. - Assistance from third parties is needed in diagnosing the cause - of the problem. - - help - The maintainer is requesting help with dealing with this bug. - - pending - A solution to this bug has been found and an upload will be made - soon. - - fixed - This bug is fixed or worked around (by a non-maintainer upload, - for example), but there's still an issue that needs to be - resolved. This tag replaces the old "fixed" severity. - - security - This bug describes a security problem in a package (e.g., bad - permissions allowing access to data that shouldn't be - accessible; buffer overruns allowing people to control a system - in ways they shouldn't be able to; denial of service attacks - that should be fixed, etc). Most security bugs should also be - set at critical or grave severity. - - upstream - This bug applies to the upstream part of the package. - - confirmed - The maintainer has looked at, understands, and basically agrees - with the bug, but has yet to fix it. (Use of this tag is - optional; it is intended mostly for maintainers who need to - manage large numbers of open bugs.) - - fixed-upstream - The bug has been fixed by the upstream maintainer, but not yet - in the package (for whatever reason: perhaps it is too - complicated to backport the change or too minor to be worth - bothering). - - fixed-in-experimental - The bug has been fixed in the package of the experimental - distribution, but not yet in the unstable distribution. - - d-i - This bug is relevant to the development of debian-installer. It - is expected that this will be used when the bug affects - installer development but is not filed against a package that - forms a direct part of the installer itself. - - ipv6 - This bug affects support for Internet Protocol version 6. - - lfs - This bug affects support for large files (over 2 gigabytes). - - l10n - This bug is relevant to the localisation of the package. - - potato - This bug particularly applies to the potato release of Debian. - - woody - This bug particularly applies to the woody distribution. - - sarge - This is a distribution tag, which has two effects. When set on a - bug, the bug can only affect sarge (though it may also affect - other distributions if other distribution tags are set) but - otherwise normal buggy/fixed/absent rules apply. The bug also - should not be archived until it is fixed in sarge. - - sarge-ignore - This release-critical bug is to be ignored for the purposes of - releasing sarge. This tag should only be used by the release - manager; do not set it yourself without explicit authorization - from them. - - etch - This is a distribution tag, which has two effects. When set on a - bug, the bug can only affect etch (though it may also affect - other distributions if other distribution tags are set) but - otherwise normal buggy/fixed/absent rules apply. The bug also - should not be archived until it is fixed in etch. - - etch-ignore - This release-critical bug is to be ignored for the purposes of - releasing etch. This tag should only be used by the release - manager; do not set it yourself without explicit authorization - from them. - - lenny - This is a release tag, which has two effects. When set on a bug, - the bug can only affect lenny (though it may also affect other - releases if other release tags are set) but otherwise normal - buggy/fixed/absent rules apply. The bug also should not be - archived until it is fixed in lenny. - - lenny-ignore - This release-critical bug is to be ignored for the purposes of - releasing lenny. This tag should only be used by the release - manager(s); do not set it yourself without explicit - authorization from them. - - squeeze - This is a release tag, which has two effects. When set on a bug, - the bug can only affect squeeze (though it may also affect other - releases if other release tags are set) but otherwise normal - buggy/fixed/absent rules apply. The bug also should not be - archived until it is fixed in squeeze. - - squeeze-ignore - This release-critical bug is to be ignored for the purposes of - releasing squeeze. This tag should only be used by the release - manager(s); do not set it yourself without explicit - authorization from them. - - sid - This is a release tag, which has two effects. When set on a bug, - the bug can only affect sid (though it may also affect other - releases if other release tags are set) but otherwise normal - buggy/fixed/absent rules apply. The bug also should not be - archived until it is fixed in sid. - - experimental - This is a release tag, which has two effects. When set on a bug, - the bug can only affect experimental (though it may also affect - other releases if other release tags are set) but otherwise - normal buggy/fixed/absent rules apply. The bug also should not - be archived until it is fixed in experimental. - - The meanings of the latter 8 distribution-specific tags have changed - recently; the -ignore tags ignore the bug for the purposes of testing - propagation. The release tags indicate that the bug in question should - not be archived until it is fixed in the set of releases specified. The - release tags also indicate that a bug should only be considered buggy - in the set of releases specified. [In other words, the bug is absent in - any release whose corresponding release tag is not set if any release - tags are set; otherwise the normal found/fixed rules apply.] - - Release tags should not be used if proper versioning of the bug would - achieve the desired effect, as they require manual addition and - removal. If you are unsure if a release tag is required, contact the - Debian BTS Administrators () or the release team for advice. - -Recording that you have passed on a bug report - - When a developer forwards a bug report to the developer of the upstream - source package from which the Debian package is derived, they should - note this in the bug tracking system as follows: - - Make sure that the To field of your message to the author has only the - author(s) address(es) in it; put the person who reported the bug, - nnn-forwarded@bugs.debian.org and nnn@bugs.debian.org in the CC field. - - Ask the author to preserve the CC to nnn-forwarded@bugs.debian.org when - they reply, so that the bug tracking system will file their reply with - the original report. These messages are only filed and are not sent on; - to send a message as normal, send them to nnn@bugs.debian.org as well. - - When the bug tracking system gets a message at nnn-forwarded it will - mark the relevant bug as having been forwarded to the address(es) in - the To field of the message it gets, if the bug is not already marked - as forwarded. - - You can also manipulate the "forwarded to" information by sending - messages to control@bugs.debian.org. - -Changing bug ownership - - In cases where the person responsible for fixing a bug is not the - assigned maintainer for the associated package (for example, when the - package is maintained by a team), it may be useful to record this fact - in the bug tracking system. To help with this, each bug may optionally - have an owner. - - The owner can be set by supplying an Owner line in the pseudo-header - when the bug is submitted (see the instructions for reporting bugs), or - by using the owner and noowner commands with the control request - server. - -Incorrectly listed package maintainers - - If the maintainer of a package is listed incorrectly, this is usually - because the maintainer has changed recently, and the new maintainer - hasn't yet uploaded a new version of the package with a changed - Maintainer control file field. This will be fixed when the package is - uploaded; alternatively, the archive maintainers can override the - maintainer record of a package manually, for example if a rebuild and - reupload of the package is not expected to be needed soon. Contact - override-change@debian.org for changes to the override file. - -Reopening, reassigning and manipulating bugs - - It is possible to reassign bug reports to other packages, to reopen - erroneously-closed ones, to modify the information saying to where, if - anywhere, a bug report has been forwarded, to change the severities and - titles of reports, to set the ownership of bugs, to merge and unmerge - bug reports, and to record the versions of packages in which bugs were - found and in which they were fixed. This is done by sending mail to - control@bugs.debian.org. - - The format of these messages is described in another document available - on the World Wide Web or in the file bug-maint-mailcontrol.txt. A plain - text version can also be obtained by mailing the word help to the - server at the address above. - -Subscribing to bugs - - The bug tracking system also allows bug submitters, developers and - other interested third parties to subscribe to individual bugs. This - feature can be used by those wishing to keep an eye on a bug, without - having to subscribe to a package through the PTS. All messages that are - received at nnn@bugs.debian.org, are sent to subscribers. - - Subscribing to a bug can be done by sending an email to - nnn-subscribe@bugs.debian.org. The subject and body of the email are - ignored by the BTS. Once this message is processed, users are sent a - confirmation message that they will need to reply to before they are - sent the messages relating to that bug. - - It is also possible to unsubscribe from a bug. Unsubscribing can be - done by sending an email to nnn-unsubscribe@bugs.debian.org. The - subject and body of the email are again ignored by the BTS. Users will - be sent a confirmation message which they must reply to if they wish to - be unsubscribed from the bug. - - By default, the address subscribed is the one found in the From header. - If you wish to subscribe another address to a bug, you will need to - encode the address to be subscribed into the subscription message. This - takes the form of: nnn-subscribe-localpart=example.com@bugs.debian.org. - That example would send localpart@example.com a subscription message - for bug nnn. The @ sign must be encoded by changing it to an = sign. - Similarly, an unsubscription takes the form - nnn-unsubscribe-localpart=example.com@bugs.debian.org. In both cases, - the subject and body of the email will be forwarded to the email - address within the request for confirmation. - -More-or-less obsolete subject-scanning feature - - Messages that arrive at submit or bugs whose Subject starts Bug#nnn - will be treated as having been sent to nnn@bugs.debian.org. This is - both for backwards compatibility with mail forwarded from the old - addresses, and to catch followup mail sent to submit by mistake (for - example, by using reply to all recipients). - - A similar scheme operates for maintonly, done, quiet and forwarded, - which treat mail arriving with a Subject tag as having been sent to the - corresponding nnn-whatever@bugs.debian.org address. - - Messages arriving at plain forwarded and done -- ie, with no bug report - number in the address -- and without a bug number in the Subject will - be filed under "junk" and kept for a few weeks, but otherwise ignored. - -Obsolete X-Debian-PR: quiet feature - - It used to be possible to prevent the bug tracking system from - forwarding anywhere messages it received at debian-bugs, by putting an - X-Debian-PR: quiet line in the actual mail header. - - This header line is now ignored. Instead, send your message to quiet or - nnn-quiet (or maintonly or nnn-maintonly). - __________________________________________________________________ diff -Nru doc-debian-4.0.2ubuntu1/doc/bug-maint-info.wml doc-debian-6.1ubuntu1/doc/bug-maint-info.wml --- doc-debian-4.0.2ubuntu1/doc/bug-maint-info.wml 2010-01-11 21:06:49.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/bug-maint-info.wml 2012-10-20 04:09:43.000000000 +0100 @@ -14,9 +14,7 @@ Reply-To will be set to include both the submitter of the report and nnn@bugs.debian.org.

    - - -
      + - - -

      Closing bug reports

      Debian bug reports should be closed when the problem is fixed. Problems @@ -76,33 +71,44 @@ header after forwarding the bug report. Please note that these are two distinct addresses.

      -

      If a developer wishes to reply to a bug report they should simply reply +

      +Any developer wishing to reply to a bug report should simply reply to the message, respecting the Reply-To header. This will not close the bug.

      -

      The bug tracking system will -receive the message at nnn@bugs.debian.org, pass it on to the -package maintainer, file the reply with the rest of the logs for that bug -report and forward it to debian-bugs-dist.

      - -

      Sending a message to nnn-submitter@bugs.debian.org -will explicitly email the submitter of the bug and place a copy in the -Bug tracking system. The message will not be sent to package maintainer.

      - -

      If you wish to send a followup message which is not appropriate for -debian-bugs-dist you can do so by sending it to -nnn-quiet@bugs.debian.org or -nnn-maintonly@bugs.debian.org. -Mail to nnn-quiet@bugs.debian.org is filed in the Bug Tracking -System but is not delivered to any individuals or mailing lists. Mail to -nnn-maintonly@bugs.debian.org is filed in the Bug Tracking -System and is delivered only to the maintainer of the package in question.

      -

      Do not use the reply to all recipients or followup feature of your mailer unless you intend to edit down the recipients substantially. In particular, see that you don't send followup messages to submit@bugs.debian.org.

      +

      +Messages can be sent to the following addresses +in order to be filed in the bug tracking system: +

      + +
        +
      • +nnn@bugs.debian.org — such messages are also sent +to the package maintainer and forwarded to debian-bugs-dist, +but not to the submitter; +
        • +
      • +nnn-submitter@bugs.debian.org — these are also sent +to the submitter and forwarded to debian-bugs-dist, +but not to the package maintainer; +
        • +
      • +nnn-maintonly@bugs.debian.org — these are only sent +to the package maintainer, not to the submitter +or debian-bugs-dist; +
        • +
      • +nnn-quiet@bugs.debian.org — these are only +filed in the bug tracking system (as are all the above), +not sent to anyone else. +
        • +
      +

      For more information about headers to suppress ACK messages and how to send carbon copies using the Bug Tracking System, see the instructions for reporting bugs.

      @@ -159,8 +165,8 @@ stable release of Debian. Currently, these are critical, grave and serious. For complete and canonical rules on what issues merit these severities, see the list of -Release-Critical -Issues for Lenny.

      +release-critical +issues for the next release.

      Tags for bug reports

      @@ -175,7 +181,8 @@ control request server. Separate multiple tags with commas, spaces, or both.

      -

      The current bug tags are:

      +

      The current bug tags are: . Here is some detailed info +about the tags:

      @@ -310,6 +317,19 @@ manager(s); do not set it yourself without explicit authorization from them. +
      wheezy
      +
      This is a release tag, which has two effects. When set on a + bug, the bug can only affect wheezy (though it may also affect + other releases if other release tags are set) but + otherwise normal buggy/fixed/absent rules apply. The bug also + should not be archived until it is fixed in wheezy.
      + +
      wheezy-ignore
      +
      This release-critical bug is to be ignored for the purposes of + releasing wheezy. This tag should only be used by the release + manager(s); do not set it yourself without explicit authorization from + them.
      +
      sid
      This is a release tag, which has two effects. When set on a bug, the bug can only affect sid (though it may also affect @@ -326,8 +346,8 @@
      -

      The meanings of the latter 8 distribution-specific tags have - changed recently; the -ignore tags ignore the bug for the purposes +

      Some info on distribution-specific tags: + the -ignore tags ignore the bug for the purposes of testing propagation. The release tags indicate that the bug in question should not be archived until it is fixed in the set of releases specified. The release tags also indicate that a bug should diff -Nru doc-debian-4.0.2ubuntu1/doc/bug-maint-mailcontrol.txt doc-debian-6.1ubuntu1/doc/bug-maint-mailcontrol.txt --- doc-debian-4.0.2ubuntu1/doc/bug-maint-mailcontrol.txt 2010-01-11 21:03:52.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/bug-maint-mailcontrol.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,414 +0,0 @@ - Introduction to the bug control and manipulation mailserver - - Just as request@bugs.debian.org allows the retrieval of bug data and - documentation by email, control@bugs.debian.org allows bug reports to - be manipulated in various ways. - - The control server works just like the request server, except that it - has some additional commands; in fact, it's the same program. The two - addresses are only separated to avoid users making mistakes and causing - problems while merely trying to request information. - - Since the commands specific to the control server actually change the - status of a bug, a notification about processing the commands is sent - to the maintainer of the package(s) the changed bugs are assigned to. - Additionally the mail to the server and the resulting changes are - logged in the bug report and thereby available in the WWW pages. - - Please see the introduction to the request server available on the - World Wide Web, in the file bug-log-mailserver.txt, or by sending help - to either mailserver, for details of the basics of operating the - mailservers and the common commands available when mailing either - address. - - The reference card for the mailservers is available via the WWW, in - bug-mailserver-refcard.txt or by email using the refcard command. - - Commands available at the control mailserver - - General Versioning Duplicates Misc. - - reassign - severity - tag - retitle - submitter - affects - summary - - found | notfound - fixed | notfixed - reopen - - merge | unmerge - forcemerge - clone - - thanks - # - forwarded | notforwarded - owner | noowner - block | unblock - archive | unarchive - - reassign bugnumber package [ version ] - Records that bug #bugnumber is a bug in package. This can be - used to set the package if the user forgot the pseudo-header, or - to change an earlier assignment. No notifications are sent to - anyone (other than the usual information in the processing - transcript). - - If you supply a version, the bug tracking system will note that - the bug affects that version of the newly-assigned package. - - You can assign a bug to two packages at once by separating the - package names with a comma. However, you should only do this if - the bug can be fixed by a change to either package. If this is - not the case, you should clone the bug and reassign the clone to - the other package. - - reopen bugnumber [ originator-address | = | ! ] - Reopens #bugnumber if it is closed. - - By default, or if you specify =, the original submitter is still - as the originator of the report, so that they will get the ack - when it is closed again. - - If you supply an originator-address the originator will be set - to the address you supply. If you wish to become the new - originator of the reopened report you can use the ! shorthand or - specify your own email address. - - It is usually a good idea to tell the person who is about to be - recorded as the originator that you're reopening the report, so - that they will know to expect the ack which they'll get when it - is closed again. - - If the bug is not closed then reopen won't do anything, not even - change the originator. To change the originator of an open bug - report, use the submitter command; note that this will inform - the original submitter of the change. - - If the bug was recorded as being closed in a particular version - of a package but recurred in a later version, it is better to - use the found command instead. - - found bugnumber [ version ] - Record that #bugnumber has been encountered in the given version - of the package to which it is assigned. - - The bug tracking system uses this information, in conjunction - with fixed versions recorded when closing bugs, to display lists - of bugs open in various versions of each package. It considers a - bug to be open when it has no fixed version, or when it has been - found more recently than it has been fixed. - - If no version is given, then the list of fixed versions for the - bug is cleared. This is identical to the behaviour of reopen. - - This command will only cause a bug to be marked as not done if - no version is specified, or if the version being marked found is - equal to the version which was last marked fixed. (If you are - certain that you want the bug marked as not done, use reopen in - conjunction with found.) - - This command was introduced in preference to reopen because it - was difficult to add a version to that command's syntax without - suffering ambiguity. - - notfound bugnumber version - Remove the record that #bugnumber was encountered in the given - version of the package to which it is assigned. - - This differs from closing the bug at that version in that the - bug is not listed as fixed in that version either; no - information about that version will be known. It is intended for - fixing mistakes in the record of when a bug was found. - - fixed bugnumber version - Indicate that bug #bugnumber was fixed in the given version of - the package to which it is assigned. - - This does not cause the bug to be marked as closed, it merely - adds another version in which the bug was fixed. Use the - bugnumber-done address to close a bug and mark it fixed in a - particular version. - - notfixed bugnumber version - Remove the record that bug #bugnumber has been fixed in the - given version. - - This command is equivalent to found followed by notfound (the - found removes the fixed at a particular version, and notfound - removes the found.) - - submitter bugnumber originator-address | ! - Changes the originator of #bugnumber to originator-address. - - If you wish to become the new originator of the report you can - use the ! shorthand or specify your own email address. - - While the reopen command changes the originator of other bugs - merged with the one being reopened, submitter does not affect - merged bugs. - - forwarded bugnumber address - Notes that bugnumber has been forwarded to the upstream - maintainer at address. This does not actually forward the - report. This can be used to change an existing incorrect - forwarded-to address, or to record a new one for a bug that - wasn't previously noted as having been forwarded. address should - generally be a URI, or possibly an email address. Using a URI - where possible allows tools to query a remote bug tracking - system (such as bugzilla) for a bug's status. - - Example usage: - - forwarded 12345 http://bugz.illa.foo/cgi/54321 - - notforwarded bugnumber - Forgets any idea that bugnumber has been forwarded to any - upstream maintainer. If the bug was not recorded as having been - forwarded then this will do nothing. - - retitle bugnumber new-title - Changes the title of a bug report to that specified (the default - is the Subject mail header from the original report). - - Unlike most of the other bug-manipulation commands when used on - one of a set of merged reports this will change the title of - only the individual bug requested, and not all those with which - it is merged. - - severity bugnumber severity - Set the severity level for bug report #bugnumber to severity. No - notification is sent to the user who reported the bug. - - Severities are critical, grave, serious, important, normal, - minor, and wishlist. - - For their meanings please consult the general developers' - documentation for the bug system. - - affects bugnumber [ + | - | = ] package [ package ... ] - Indicates that a bug affects another package. In the case where - bugnumber causes breakage in package even though the bug is - actually present in the package to which it is assigned, this - causes the bug to be listed by default in the package list of - package. This should generally be used where the bug is severe - enough to cause multiple reports from users to be assigned to - the wrong package. - - summary bugnumber [message number] - Selects a message to use as a summary of a bug. The first - non-pseudoheader paragraph of that bug is parsed and set as the - summary of the bug which is displayed on the top of the bug - report page. This is useful in cases where the original report - doesn't correctly describe the problem or the bug has many - messages which make it difficult to identify the actual problem. - - If message number is not given, clears the summary. message - number is the message number as listed in the bugreport cgi - script output. - - clone bugnumber NewID [ new IDs ... ] - The clone control command allows you to duplicate a bug report. - It is useful in the case where a single report actually - indicates that multiple distinct bugs have occurred. "New IDs" - are negative numbers, separated by spaces, which may be used in - subsequent control commands to refer to the newly duplicated - bugs. A new report is generated for each new ID. - - Example usage: - - clone 12345 -1 -2 - reassign -1 foo - retitle -1 foo: foo sucks - reassign -2 bar - retitle -2 bar: bar sucks when used with foo - severity -2 wishlist - clone 123456 -3 - reassign -3 foo - retitle -3 foo: foo sucks - merge -1 -3 - - merge bugnumber bugnumber ... - Merges two or more bug reports. When reports are merged opening, - closing, marking or unmarking as forwarded and reassigning any - of the bugs to a new package will have an identical effect on - all of the merged reports. - - Before bugs can be merged they must be in exactly the same - state: either all open or all closed, with the same forwarded-to - upstream author address or all not marked as forwarded, all - assigned to the same package or package(s) (an exact string - comparison is done on the package to which the bug is assigned), - and all of the same severity. If they don't start out in the - same state you should use reassign, reopen and so forth to make - sure that they are before using merge. Titles are not required - to match, and will not be affected by the merge. Tags are not - required to match, either, they will be joined. - - If any of the bugs listed in a merge command is already merged - with another bug then all the reports merged with any of the - ones listed will all be merged together. Merger is like - equality: it is reflexive, transitive and symmetric. - - Merging reports causes a note to appear on each report's logs; - on the WWW pages this is includes links to the other bugs. - - Merged reports are all expired simultaneously, and only when all - of the reports each separately meet the criteria for expiry. - - forcemerge bugnumber bugnumber ... - Forcibly merges two or more bug reports. The first bug listed is - the master bug, and its settings (the settings which must be - equal in a normal merge) are assigned to the bugs listed next. - To avoid typos erroneously merging bugs, bugs must be in the - same package. See the text above for a description of what - merging means. - - Note that this makes it possible to close bugs by merging; you - are responsible for notifying submitters with an appropriate - close message if you do this. - - unmerge bugnumber - Disconnects a bug report from any other reports with which it - may have been merged. If the report listed is merged with - several others then they are all left merged with each other; - only their associations with the bug explicitly named are - removed. - - If many bug reports are merged and you wish to split them into - two separate groups of merged reports you must unmerge each - report in one of the new groups separately and then merge them - into the required new group. - - You can only unmerge one report with each unmerge command; if - you want to disconnect more than one bug simply include several - unmerge commands in your message. - - tags bugnumber [ + | - | = ] tag [ tag ... ] [ + | - | = tag ... ] ] - Sets tags for the bug report #bugnumber. No notification is sent - to the user who reported the bug. Setting the action to + means - to add each tag following, - means to remove each tag following, - and = means to set the following tags to the list provided. - Intervening +, -, or = change the action for the tags following. - The default action is adding. - - Example usage: - - # same as 'tags 123456 + patch' - tags 123456 patch - - # same as 'tags 123456 + help security' - tags 123456 help security - - # add 'fixed' and 'pending' tags - tags 123456 + fixed pending - - # remove 'unreproducible' tag - tags 123456 - unreproducible - - # set tags to exactly 'moreinfo' and 'unreproducible' - tags 123456 = moreinfo unreproducible - - # remove the moreinfo tag and add a patch tag - tags 123456 - moreinfo + patch - - Available tags currently include patch, wontfix, moreinfo, - unreproducible, help, pending, fixed, fixed-in-experimental, - fixed-upstream, security, upstream, confirmed, d-i, ipv6, lfs, - l10n, potato, woody, sarge, sarge-ignore, etch, etch-ignore, - lenny, lenny-ignore, squeeze, squeeze-ignore, sid, and - experimental. - - For their meanings please consult the general developers' - documentation for the bug system. - - block bugnumber by bug ... - Note that the fix for the first bug is blocked by the other - listed bugs. - - unblock bugnumber by bug ... - Note that the fix for the first bug is no longer blocked by the - other listed bugs. - - close bugnumber [ fixed-version ] (deprecated) - Close bug report #bugnumber. - - A notification is sent to the user who reported the bug, but (in - contrast to mailing bugnumber-done@bugs.debian.org) the text of - the mail which caused the bug to be closed is not included in - that notification. The maintainer who closes a report needs to - ensure, probably by sending a separate message, that the user - who reported the bug knows why it is being closed. The use of - this command is therefore deprecated. See the developer's - information about how to close a bug properly. - - If you supply a fixed-version, the bug tracking system will note - that the bug was fixed in that version of the package. - - package [ packagename ... ] - Limits the following commands so that they will only apply to - bugs filed against the listed packages. You can list one or more - packages. If you don't list any packages, the following commands - will apply to all bugs. You're encouraged to use this as a - safety feature in case you accidentally use the wrong bug - numbers. - - Example usage: - - package foo - reassign 123456 bar 1.0-1 - - package bar - retitle 123456 bar: bar sucks - severity 123456 normal - - package - severity 234567 wishlist - - owner bugnumber address | ! - Sets address to be the "owner" of #bugnumber. The owner of a bug - claims responsibility for fixing it. This is useful to share out - work in cases where a package has a team of maintainers. - - If you wish to become the owner of the bug yourself, you can use - the ! shorthand or specify your own email address. - - noowner bugnumber - Forgets any idea that the bug has an owner other than the usual - maintainer. If the bug had no owner recorded then this will do - nothing. - - archive bugnumber - Archives a bug that had been archived at some point in the past - but is currently not archived if the bug fulfills the - requirements for archival, ignoring time. - - unarchive bugnumber - Unarchives a bug that was previously archived. Unarchival should - generally be coupled with reopen and found/fixed as appropriate. - Bugs that have been unarchived can be archived using archive - assuming the non-time based archival requirements are met. - - #... - One-line comment. The # must be at the start of the line. The - text of comments will be included in the acknowledgement sent to - the sender and to affected maintainers, so you can use this to - document the reasons for your commands. - - quit - stop - thank - thanks - thankyou - thank you - -- - On a line by itself, in any case, possibly followed by - whitespace, tells the control server to stop processing the - message; the remainder of the message can include explanations, - signatures or anything else, none of it will be detected by the - control server. - __________________________________________________________________ diff -Nru doc-debian-4.0.2ubuntu1/doc/bug-maint-mailcontrol.wml doc-debian-6.1ubuntu1/doc/bug-maint-mailcontrol.wml --- doc-debian-4.0.2ubuntu1/doc/bug-maint-mailcontrol.wml 2010-01-11 21:03:52.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/bug-maint-mailcontrol.wml 2012-10-20 04:09:43.000000000 +0100 @@ -43,8 +43,7 @@

      Commands available at the control mailserver

      -
      - +
      @@ -54,47 +53,47 @@
      General Versioning
      -
      -
      reassign
      -
      severity
      -
      tag
      -
      retitle
      -
      submitter
      -
      affects
      -
      summary
      -
      +       		-
      -
      found | notfound
      -
      fixed | notfixed
      -
      reopen
      +
      +       		-
      -
      merge | unmerge
      -
      forcemerge
      -
      clone
      -
      +       		-
      -
      thanks
      -
      #
      -
      forwarded | notforwarded
      -
      owner | noowner
      -
      block | unblock
      -
      archive | unarchive
      -
      +
      -
      reassign bugnumber @@ -171,6 +170,8 @@

      Record that #bugnumber has been encountered in the given version of the package to which it is assigned. + version may be a fully qualified version, + of the form sourcepackagename/version.

      @@ -185,14 +186,17 @@ If no version is given, then the list of fixed versions for the bug is cleared. This is identical to the behaviour of reopen. + version may be a fully qualified version, of the + form sourcepackagename/version.

      This command will only cause a bug to be marked as not done if no - version is specified, or if the version being marked found - is equal to the version which was last marked fixed. (If - you are certain that you want the bug marked as not done, - use reopen in conjunction with found.) + version is specified, or if the version being marked + found is equal to or greater than the highest version + marked fixed. (If you are certain that you want the bug marked as + not done, use reopen in conjunction + with found.)

      @@ -209,6 +213,8 @@

      Remove the record that #bugnumber was encountered in the given version of the package to which it is assigned. + version may be a fully qualified version, of + the form sourcepackagename/version.

      @@ -226,6 +232,8 @@

      Indicate that bug #bugnumber was fixed in the given version of the package to which it is assigned. + version may be a fully qualified version, of the + form sourcepackagename/version.

      @@ -243,12 +251,18 @@

      Remove the record that bug #bugnumber has been fixed in the given version. + version may be a fully qualified version, of the + form sourcepackagename/version.

      This command is equivalent to found followed by notfound (the found removes the fixed at a particular - version, and notfound removes the found.) + version, and notfound removes the found) with the exception that + the bug is not reopened if the found version is greater than any + existing fixed version. It is intended for fixing mistakes in the + record of when a bug was fixed; in most cases, you actually want + found, not notfixed.

      @@ -315,12 +329,8 @@

      Changes the title of a bug report to that specified (the default is the Subject mail header from the original report). -

      - -

      - Unlike most of the other bug-manipulation commands when used on one of - a set of merged reports this will change the title of only the - individual bug requested, and not all those with which it is merged. + Will also change the titles of all bug reports which this bug is + merged with.

      @@ -335,9 +345,7 @@

      - Severities are critical, grave, - serious, important, normal, - minor, and wishlist. + Severities are .

      @@ -357,16 +365,21 @@ it is assigned, this causes the bug to be listed by default in the package list of package. This should generally be used where the bug is severe enough to cause multiple reports - from users to be assigned to the wrong package. + from users to be assigned to the wrong package. = + sets the affects to the list of packages given, and is the + default action if no packages are given; - removes + the given packages from the affects list; + adds + the given packages to the affects list, and is the default if + packages are given.

      summary bugnumber - [message number]
      + [message number | summary text]

      Selects a message to use as a summary of a bug. The first - non-pseudoheader paragraph of that bug is parsed and set as the + non-pseudoheader/non-control paragraph of that message is parsed and set as the summary of the bug which is displayed on the top of the bug report page. This is useful in cases where the original report doesn't correctly describe the problem or the bug has many @@ -375,7 +388,43 @@

      If message number is not given, clears the summary. message number is the message number as - listed in the bugreport cgi script output. + listed in the bugreport cgi script output; if + a message number of 0 is given, the current message + is used (that is, the message which was sent to + control@bugs.debian.org which contains the summary control + command). +

      +

      + If message number is not numerical and not the empty + string, it is assumed to be the text to set the summary to. +

      +
      + +
      outlook bugnumber + [message number | outlook text]
      +
      +

      + Selects a message to use as the outlook for fixing a bug (or the + current status of fixing a bug). The first + non-pseudoheader/non-control paragraph of that message is parsed + and set as the outlook of the bug which is displayed on the top + of the bug report page. This is useful to coordinate with others + who are working on fixing this bug (for example, in an bug + squashing party). +

      +

      + If message number is not given, clears the + outlook. message number is the message number as + listed in the bugreport cgi script output; if + a message number of 0 is given, the current message + is used (that is, the message which was sent to + control@bugs.debian.org which contains the outlook control + command). +

      +

      + If message number is not numerical and not the empty + string, it is assumed to be the text to set the outlook to. +

      @@ -456,12 +505,11 @@ bugnumber ...

      - Forcibly merges two or more bug reports. The first bug listed - is the master bug, and its settings (the settings which must be equal in - a normal merge) are assigned to the bugs listed next. - To avoid typos erroneously merging bugs, bugs must be in - the same package. See the text above for a description of what - merging means. + Forcibly merges two or more bug reports. The settings of the first + bug listed which must be equal in a normal merge are assigned to + the bugs listed next. To avoid typos erroneously merging bugs, + bugs must be in the same package. See the text above for a + description of what merging means.

      @@ -496,7 +544,7 @@

      -
      tags bugnumber [ + | +
      tags bugnumber [ + | - | = ] tag [ tag ... ] [ + | - | = tag ... ] ]
      @@ -537,18 +585,7 @@

      - Available tags currently include patch, wontfix, - moreinfo, unreproducible, help, - pending, fixed, - fixed-in-experimental, fixed-upstream, - security, - upstream, confirmed, d-i, - ipv6, lfs, l10n, - potato, woody, sarge, - sarge-ignore, etch, etch-ignore, - lenny, lenny-ignore, - squeeze, squeeze-ignore, - sid, and experimental. + Available tags currently include .

      @@ -665,7 +702,11 @@ Unarchives a bug that was previously archived. Unarchival should generally be coupled with reopen and found/fixed as appropriate. Bugs that have been unarchived can be archived using archive assuming the - non-time based archival requirements are met. + non-time based archival requirements are met. You should not be + using unarchive to make trivial changes to archived bugs, such as + changing the submitter; its primary purpose is to allow for the + reopening of bugs which have been archived without the + intervention of BTS administrators. diff -Nru doc-debian-4.0.2ubuntu1/doc/bug-reporting.txt doc-debian-6.1ubuntu1/doc/bug-reporting.txt --- doc-debian-4.0.2ubuntu1/doc/bug-reporting.txt 2010-01-11 21:03:53.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/bug-reporting.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,364 +0,0 @@ - How to report a bug in Debian using reportbug - - We strongly recommend that you report bugs in Debian using the - reportbug program. To install and start it, simply run: - - aptitude install reportbug; reportbug - - It will guide you through the bug reporting process step by step. - - If you have questions that the interactive prompts of reportbug do not - resolve, you can refer to the rest of the documentation below or ask - the Debian user mailing list. - - How to report a bug in Debian using email (and advanced usage of reportbug) - -Important things to note before sending your bug report - - What package does your bug report belong to? - - You need to know what package your bug report should be filed against. - See this example for information on how to find this information. (You - will use this information to see if your bug report has been filed - already.) - - If you are unable to determine which package your bug report should be - filed against, please send e-mail to the Debian user mailing list - asking for advice. - - If your problem doesn't relate just to one package but some general - Debian service, there are several pseudo-packages or even mailing lists - that you can use to relay your message to us instead. - - Has your bug report been filed already? - - You should check to see if your bug report has already been filed - before submitting it. You can see which bugs have been filed in a - specific package using the package option of the bug search form. If - there is an existing bug report #, you should submit your - comments by sending e-mail to @bugs.debian.org instead of - reporting a new bug. - - Send multiple reports for multiple bugs - - Please don't report multiple unrelated bugs -- especially ones in - different packages -- in a single bug report. - - Don't file bugs upstream - - If you file a bug in Debian, don't send a copy to the upstream software - maintainers yourself, as it is possible that the bug exists only in - Debian. If necessary, the maintainer of the package will forward the - bug upstream. - -Sending the bug report via e-mail - - You can report bugs in Debian by sending an e-mail to - submit@bugs.debian.org with a special format described below. reportbug - (see above) will properly format the e-mails for you; please use it! - - Headers - - Like any e-mail you should include a clear, descriptive Subject line in - your main mail header. The subject you give will be used as the initial - bug title in the tracking system, so please try to make it informative! - - If you'd like to send a copy of your bug report to additional - recipients (such as mailing lists), you shouldn't use the usual e-mail - headers, but a different method, described below. - - Pseudo-headers - - The first part of the bug report are the pseudo-headers which contain - information about what package and version your bug report applies to. - The first line of the message body has to include a pseudo-header. It - should say: -Package: - - Replace with the name of the package which has the bug. - - The second line of the message should say: -Version: - - Replace with the version of the package. Please don't - include any text here other than the version itself, as the bug - tracking system relies on this field to work out which releases are - affected by the bug. - - You need to supply a correct Package line in the pseudo-header in order - for the bug tracking system to deliver the message to the package's - maintainer. See this example for information on how to find this - information. - - For other valid pseudo-headers, see Additional pseudo-headers - - The body of the report - - Please include in your report: - * The exact and complete text of any error messages printed or - logged. This is very important! - * Exactly what you typed or did to demonstrate the problem. - * A description of the incorrect behavior: exactly what behavior you - were expecting, and what you observed. A transcript of an example - session is a good way of showing this. - * A suggested fix, or even a patch, if you have one. - * Details of the configuration of the program with the problem. - Include the complete text of its configuration files. - * The versions of any packages on which the buggy package depends. - * What kernel version you're using (type uname -a), your shared C - library (type ls -l /lib/libc.so.6 or dpkg -s libc6 | grep - ^Version), and any other details about your Debian system, if it - seems appropriate. For example, if you had a problem with a Perl - script, you would want to provide the version of the `perl' binary - (type perl -v or dpkg -s perl | grep ^Version:). - * Appropriate details of the hardware in your system. If you're - reporting a problem with a device driver please list all the - hardware in your system, as problems are often caused by IRQ and - I/O address conflicts. - * If you have reportbug installed the output of reportbug -q - --template -T none -s none -S normal -b --list-cc none -q - will also be useful, as it contains the output of maintainer - specific scripts and version information. - - Include any detail that seems relevant -- you are in very little danger - of making your report too long by including too much information. If - they are small, please include in your report any files you were using - to reproduce the problem. (If they are large, consider making them - available on a publicly available website if possible.) - - For more advice on how to help the developers solve your problem, - please read How to Report Bugs Effectively. - -An Example Bug Report - - A bug report with header and pseudo-header looks something like this: - To: submit@bugs.debian.org - From: diligent@testing.linux.org - Subject: Hello says `goodbye' - - Package: hello - Version: 1.3-16 - - When I invoke `hello' without arguments from an ordinary shell - prompt it prints `goodbye', rather than the expected `hello, world'. - Here is a transcript: - - $ hello - goodbye - $ /usr/bin/hello - goodbye - $ - - I suggest that the output string, in hello.c, be corrected. - - I am using Debian GNU/Linux 2.2, kernel 2.2.17-pre-patch-13 - and libc6 2.1.3-10. - -Sending copies of bug reports to other addresses - - Sometimes it is necessary to send a copy of a bug report to somewhere - else besides debian-bugs-dist and the package maintainer, which is - where they are normally sent. - - You could do this by CC'ing your bug report to the other address(es), - but then the other copies would not have the bug report number put in - the Reply-To field and the Subject line. When the recipients reply they - will probably preserve the submit@bugs.debian.org entry in the header - and have their message filed as a new bug report. This leads to many - duplicated reports. - - The right way to do this is to use the X-Debbugs-CC header. Add a line - like this to your message's mail header: - X-Debbugs-CC: other-list@cosmic.edu - - This will cause the bug tracking system to send a copy of your report - to the address(es) in the X-Debbugs-CC line as well as to - debian-bugs-dist. - - Avoid sending such copies to the addresses of other bug reports, as - they will be caught by the checks that prevent mail loops. There is - relatively little point in using X-Debbugs-CC for this anyway, as the - bug number added by that mechanism will just be replaced by a new one; - use an ordinary CC header instead. - - This feature can often be combined usefully with mailing quiet -- see - below. - - Additional Pseudoheaders - -Severity levels - - If a report is of a particularly serious bug, or is merely a feature - request, you can set the severity level of the bug as you report it. - This is not required however, and the package maintainer will assign an - appropriate severity level to your report even if you do not (or pick - the wrong severity). - - To assign a severity level, put a line like this one in the - pseudo-header: -Severity: - - Replace with one of the available severity levels, as - described in the advanced documentation. - -Assigning tags - - You can set tags on a bug as you are reporting it. For example, if you - are including a patch with your bug report, you may wish to set the - patch tag. This is not required, however, and the developers will set - tags on your report as and when it is appropriate. - - To set tags, put a line like this one in the pseudo-header: -Tags: - - Replace with one or more of the available tags, as described in - the advanced documentation. Separate multiple tags with commas, spaces, - or both. -User: -Usertags: - - Replace with one or more usertags. Separate multiple tags - with commas, spaces, or both. If you specify a , that user's - tags will be set. Otherwise, the e-mail address of the sender will be - used as the username. -Forwarded: foo@example.com - - will mark the newly submitted bug as forwarded to foo@example.com. See - Recording that you have passed on a bug report in the developers' - documentation for details. -Owner: foo@example.com - - will indicate that foo@example.com is now responsible for fixing this - bug. See Changing bug ownership in the developers' documentation for - details. -Source: foopackage - - the equivalent of Package: for bugs present in the source package of - foopackage; for most bugs in most packages you don't want to use this - option. - - Finally, if your MUA doesn't allow you to edit the headers, you can set - the various X-Debbugs- headers in the pseudo-headers. - - Additional information - -Different submission addresses (minor or mass bug reports) - - If a bug report is minor, for example, a documentation typo or a - trivial build problem, please adjust the severity appropriately and - send it to maintonly@bugs.debian.org instead of submit@bugs.debian.org. - maintonly will forward the report to the package maintainer only, it - won't forward it to the BTS mailing lists. - - If you're submitting many reports at once, you should definitely use - maintonly@bugs.debian.org so that you don't cause too much redundant - traffic on the BTS mailing lists. Before submitting many similar bugs - you may also want to post a summary on debian-bugs-dist. - - If wish to report a bug to the bug tracking system that's already been - sent to the maintainer, you can use quiet@bugs.debian.org. Bugs sent to - quiet@bugs.debian.org will not be forwarded anywhere, only filed. - - When you use different submission addresses, the bug tracking system - will set the Reply-To of any forwarded message so that the replies will - by default be processed in the same way as the original report. That - means that, for example, replies to maintonly will go to - nnn-maintonly@bugs.debian.org instead of nnn@bugs.debian.org, unless of - course one overrides this manually. - -Acknowledgements - - Normally, the bug tracking system will return an acknowledgement to you - by e-mail when you report a new bug or submit additional information to - an existing bug. If you want to suppress this acknowledgement, include - an X-Debbugs-No-Ack header in your e-mail (the contents of this header - do not matter; however, it must be in the mail header and not in the - pseudo-header with the Package field). If you report a new bug with - this header, you will need to check the web interface yourself to find - the bug number. - - Note that this header will not suppress acknowledgements from the - control@bugs.debian.org mailserver, since those acknowledgements may - contain error messages which should be read and acted upon. - -Spamfighting and missing mail - - The bug tracking system implements a rather extensive set of rules - designed to make sure that spam does not make it through the BTS. While - we try to minimize the number of false positives, they do occur. If you - suspect your mail has triggered a false positive, feel free to contact - owner@bugs.debian.org for assistance. Another common cause of mail not - making it through to the BTS is utilizing addresses which match - procmail's FROM_DAEMON, which includes mail from addresses like - mail@foobar.com. If you suspect your mail matches FROM_DAEMON, see - procmailrc(5) to verify, and then resend the mail using an address - which does not match FROM_DAEMON. - -Bug reports against unknown packages - - If the bug tracking system doesn't know who the maintainer of the - relevant package is it will forward the report to debian-bugs-dist even - if maintonly was used. - - When sending to maintonly@bugs.debian.org or - nnn-maintonly@bugs.debian.org you should make sure that the bug report - is assigned to the right package, by putting a correct Package at the - top of an original submission of a report, or by using the - control@bugs.debian.org service to (re)assign the report appropriately. - -Using dpkg to find the package and version for the report - - When using reportbug to report a bug in a command, say grep, the - following will automatically select the right package and let you write - the report right away: reportbug --file $(which grep) - - You can also find out which package installed it by using dpkg - --search. You can find out which version of a package you have - installed by using dpkg --list or dpkg --status. - - For example: -$ which apt-get -/usr/bin/apt-get -$ type apt-get -apt-get is /usr/bin/apt-get -$ dpkg --search /usr/bin/apt-get -apt: /usr/bin/apt-get -$ dpkg --list apt -Desired=Unknown/Install/Remove/Purge/Hold -| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed -|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) -||/ Name Version Description -+++-==============-==============-============================================ -ii apt 0.3.19 Advanced front-end for dpkg -$ dpkg --status apt -Package: apt -Status: install ok installed -Priority: standard -Section: base -Installed-Size: 1391 -Maintainer: APT Development Team -Version: 0.3.19 -Replaces: deity, libapt-pkg-doc (<< 0.3.7), libapt-pkg-dev (<< 0.3.7) -Provides: libapt-pkg2.7 -Depends: libapt-pkg2.7, libc6 (>= 2.1.2), libstdc++2.10 -Suggests: dpkg-dev -Conflicts: deity -Description: Advanced front-end for dpkg - This is Debian's next generation front-end for the dpkg package manager. - It provides the apt-get utility and APT dselect method that provides a - simpler, safer way to install and upgrade packages. - . - APT features complete installation ordering, multiple source capability - and several other unique features, see the Users Guide in - /usr/doc/apt/guide.text.gz - - -Other useful commands and packages - - The querybts tool, available from the same package as reportbug, - provides a convenient text-based interface to the bug tracking system. - - Emacs users can also use the debian-bug command provided by the - debian-el package. When called with M-x debian-bug, it will ask for all - necessary information in a similar way to reportbug. - __________________________________________________________________ diff -Nru doc-debian-4.0.2ubuntu1/doc/bug-reporting.wml doc-debian-6.1ubuntu1/doc/bug-reporting.wml --- doc-debian-4.0.2ubuntu1/doc/bug-reporting.wml 2010-01-11 21:03:53.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/bug-reporting.wml 2012-10-20 04:09:43.000000000 +0100 @@ -7,7 +7,10 @@ href="http://packages.debian.org/stable/utils/reportbug">reportbug program. To install and start it, simply run:

      -
      aptitude install reportbug; reportbug
      +
      +

      # aptitude install reportbug
      + $ reportbug

      +

      It will guide you through the bug reporting process step by step.

      @@ -272,6 +275,7 @@ <username>, that user's tags will be set. Otherwise, the e-mail address of the sender will be used as the username.

      +

      Setting Forwarded

       Forwarded: foo@example.com
      @@ -282,6 +286,7 @@ report in the developers' documentation for details.

      +

      Claiming ownership

       Owner: foo@example.com
      @@ -292,6 +297,7 @@ developers' documentation for details.

      +

      Source Package

       Source: foopackage
      @@ -302,6 +308,20 @@ to use this option.

      +

      Control Commands

      +
      +Control: control commands
+
      + +

      +Allows for any of the commands which must be sent to +control@bugs.debian.org to work when sent to submit@bugs.debian.org or +nnn@bugs.debian.org. Please see the server + control documentation for more information on the control +commands which are valid.

      + + +

      X-Debbugs- headers

      Finally, if your MUA doesn't allow you to edit the headers, you can @@ -342,11 +362,10 @@

      Normally, the bug tracking system will return an acknowledgement to you by e-mail when you report a new bug or submit additional information to an existing bug. If you want to suppress this acknowledgement, include an -X-Debbugs-No-Ack header in your e-mail (the contents of this -header do not matter; however, it must be in the mail header and -not in the pseudo-header with the Package field). If -you report a new bug with this header, you will need to check the web -interface yourself to find the bug number.

      +X-Debbugs-No-Ack header or pseudoheader in your e-mail +(the contents of this header do not matter). If you report a new bug +with this header, you will need to check the web interface yourself to +find the bug number.

      Note that this header will not suppress acknowledgements from the control@bugs.debian.org mailserver, since those acknowledgements may diff -Nru doc-debian-4.0.2ubuntu1/doc/constitution.1.0.txt doc-debian-6.1ubuntu1/doc/constitution.1.0.txt --- doc-debian-4.0.2ubuntu1/doc/constitution.1.0.txt 2010-01-11 21:03:53.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/constitution.1.0.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,597 +0,0 @@ - Historical version of the Constitution for the Debian Project (v1.0) - - Version 1.0 ratified on December 2nd, 1998. Superseded by Version 1.1 - ratified on June 21st, 2003, which is itself superseded by version 1.2, - ratified on October 29th, 2003. Version 1.2 was again superseded by - version 1.3 ratified on September 24th, 2006. That was superceded by - the current version ratified on October 7th, 2007. - -1. Introduction - - The Debian Project is an association of individuals who have made - common cause to create a free operating system. - - This document describes the organisational structure for formal - decision-making in the Project. It does not describe the goals of the - Project or how it achieves them, or contain any policies except those - directly related to the decision-making process. - -2. Decision-making bodies and individuals - - Each decision in the Project is made by one or more of the following: - 1. The Developers, by way of General Resolution or an election; - 2. The Project Leader; - 3. The Technical Committee and/or its Chairman; - 4. The individual Developer working on a particular task; - 5. Delegates appointed by the Project Leader for specific tasks; - 6. The Project Secretary. - - Most of the remainder of this document will outline the powers of these - bodies, their composition and appointment, and the procedure for their - decision-making. The powers of a person or body may be subject to - review and/or limitation by others; in this case the reviewing body or - person's entry will state this. In the list above, a person or body is - usually listed before any people or bodies whose decisions they can - overrule or who they (help) appoint - but not everyone listed earlier - can overrule everyone listed later. - - 2.1. General rules - - 1. Nothing in this constitution imposes an obligation on anyone to do - work for the Project. A person who does not want to do a task which - has been delegated or assigned to them does not need to do it. - However, they must not actively work against these rules and - decisions properly made under them. - 2. A person may hold several posts, except that the Project Leader, - Project Secretary and the Chairman of the Technical Committee must - be distinct, and that the Leader cannot appoint themselves as their - own Delegate. - 3. A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly. - -3. Individual Developers - - 3.1. Powers - - An individual Developer may - 1. make any technical or nontechnical decision with regard to their - own work; - 2. propose or sponsor draft General Resolutions; - 3. propose themselves as a Project Leader candidate in elections; - 4. vote on General Resolutions and in Leadership elections. - - 3.2. Composition and appointment - - 1. Developers are volunteers who agree to further the aims of the - Project insofar as they participate in it, and who maintain - package(s) for the Project or do other work which the Project - Leader's Delegate(s) consider worthwhile. - 2. The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. If the Developers feel - that the Delegates are abusing their authority they can of course - override the decision by way of General Resolution - see §4.1(3), - §4.2. - - 3.3. Procedure - - Developers may make these decisions as they see fit. - -4. The Developers by way of General Resolution or election - - 4.1. Powers - - Together, the Developers may: - 1. Appoint or recall the Project Leader. - 2. Amend this constitution, provided they agree with a 3:1 majority. - 3. Override any decision by the Project Leader or a Delegate. - 4. Override any decision by the Technical Committee, provided they - agree with a 2:1 majority. - 5. Issue nontechnical policy documents and statements. - These include documents describing the goals of the project, its - relationship with other free software entities, and nontechnical - policies such as the free software licence terms that Debian - software must meet. - They may also include position statements about issues of the day. - 6. Together with the Project Leader and SPI, make decisions about - property held in trust for purposes related to Debian. (See §9.1.) - - 4.2. Procedure - - 1. The Developers follow the Standard Resolution Procedure, below. A - resolution or amendment is introduced if proposed by any Developer - and sponsored by at least K other Developers, or if proposed by the - Project Leader or the Technical Committee. - 2. Delaying a decision by the Project Leader or their Delegate: - 1. If the Project Leader or their Delegate, or the Technical - Committee, has made a decision, then Developers can override - them by passing a resolution to do so; see §4.1(3). - 2. If such a resolution is sponsored by at least 2K Developers, - or if it is proposed by the Technical Committee, the - resolution puts the decision immediately on hold (provided - that resolution itself says so). - 3. If the original decision was to change a discussion period or - a voting period, or the resolution is to override the - Technical Committee, then only K Developers need to sponsor - the resolution to be able to put the decision immediately on - hold. - 4. If the decision is put on hold, an immediate vote is held to - determine whether the decision will stand until the full vote - on the decision is made or whether the implementation of the - original decision will be delayed until then. There is no - quorum for this immediate procedural vote. - 5. If the Project Leader (or the Delegate) withdraws the original - decision, the vote becomes moot, and is no longer conducted. - 3. Votes are taken by the Project Secretary. Votes and tallies results - are not be revealed during the voting period; after the vote the - Project Secretary lists all the votes cast. The voting period is 2 - weeks, but may be varied by up to 1 week by the Project Leader, and - may be ended by the Project Secretary when the outcome of a vote is - no longer in doubt. - 4. The minimum discussion period is 2 weeks, but may be varied by up - to 1 week by the Project Leader. The Project Leader has a casting - vote. There is a quorum of 3Q. - 5. Proposals, sponsors, amendments, calls for votes and other formal - actions are made by announcement on a publicly-readable electronic - mailing list designated by the Project Leader's Delegate(s); any - Developer may post there. - 6. Votes are cast by email in a manner suitable to the Secretary. The - Secretary determines for each poll whether voters can change their - votes. - 7. Q is half of the square root of the number of current Developers. K - is Q or 5, whichever is the smaller. Q and K need not be integers - and are not rounded. - -5. Project Leader - - 5.1. Powers - - The Project Leader may: - 1. Appoint Delegates or delegate decisions to the Technical Committee. - The Leader may define an area of ongoing responsibility or a - specific decision and hand it over to another Developer or to the - Technical Committee. - Once a particular decision has been delegated and made the Project - Leader may not withdraw that delegation; however, they may withdraw - an ongoing delegation of particular area of responsibility. - 2. Lend authority to other Developers. - The Project Leader may make statements of support for points of - view or for other members of the project, when asked or otherwise; - these statements have force if and only if the Leader would be - empowered to make the decision in question. - 3. Make any decision which requires urgent action. - This does not apply to decisions which have only become gradually - urgent through lack of relevant action, unless there is a fixed - deadline. - 4. Make any decision for whom noone else has responsibility. - 5. Propose draft General Resolutions and amendments. - 6. Together with the Technical Committee, appoint new members to the - Committee. (See §6.2.) - 7. Use a casting vote when Developers vote. - The Project Leader also has a normal vote in such ballots. - 8. Vary the discussion period for Developers' votes (as above). - 9. Lead discussions amongst Developers. - The Project Leader should attempt to participate in discussions - amongst the Developers in a helpful way which seeks to bring the - discussion to bear on the key issues at hand. The Project Leader - should not use the Leadership position to promote their own - personal views. - 10. Together with SPI, make decisions affecting property held in trust - for purposes related to Debian. (See §9.1.) - - 5.2. Appointment - - 1. The Project Leader is elected by the Developers. - 2. The election begins nine weeks before the leadership post becomes - vacant, or (if it is too late already) immediately. - 3. For the following three weeks any Developer may nominate themselves - as a candidate Project Leader. - 4. For three weeks after that no more candidates may be nominated; - candidates should use this time for campaigning (to make their - identities and positions known). If there are no candidates at the - end of the nomination period then the nomination period is extended - for three further weeks, repeatedly if necessary. - 5. The next three weeks are the polling period during which Developers - may cast their votes. Votes in leadership elections are kept - secret, even after the election is finished. - 6. The options on the ballot will be those candidates who have - nominated themselves and have not yet withdrawn, plus None Of The - Above. If None Of The Above wins the election then the election - procedure is repeated, many times if necessary. - 7. The decision will be made using Concorde Vote Counting. The quorum - is the same as for a General Resolution (§4.2) and the default - option is None Of The Above. - 8. The Project Leader serves for one year from their election. - - 5.3. Procedure - - The Project Leader should attempt to make decisions which are - consistent with the consensus of the opinions of the Developers. - - Where practical the Project Leader should informally solicit the views - of the Developers. - - The Project Leader should avoid overemphasizing their own point of view - when making decisions in their capacity as Leader. - -6. Technical committee - - 6.1. Powers - - The Technical Committee may: - 1. Decide on any matter of technical policy. - This includes the contents of the technical policy manuals, - developers' reference materials, example packages and the behaviour - of non-experimental package building tools. (In each case the usual - maintainer of the relevant software or documentation makes - decisions initially, however; see 6.3(5).) - 2. Decide any technical matter where Developers' jurisdictions - overlap. - In cases where Developers need to implement compatible technical - policies or stances (for example, if they disagree about the - priorities of conflicting packages, or about ownership of a command - name, or about which package is responsible for a bug that both - maintainers agree is a bug, or about who should be the maintainer - for a package) the technical committee may decide the matter. - 3. Make a decision when asked to do so. - Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it. - 4. Overrule a Developer (requires a 3:1 majority). - The Technical Committee may ask a Developer to take a particular - technical course of action even if the Developer does not wish to; - this requires a 3:1 majority. For example, the Committee may - determine that a complaint made by the submitter of a bug is - justified and that the submitter's proposed solution should be - implemented. - 5. Offer advice. - The Technical Committee may make formal announcements about its - views on any matter. Individual members may of course make informal - statements about their views and about the likely views of the - committee. - 6. Together with the Project Leader, appoint new members to itself or - remove existing members. (See §6.2.) - 7. Appoint the Chairman of the Technical Committee. - The Chairman is elected by the Committee from its members. All - members of the committee are automatically nominated; the committee - vote starting one week before the post will become vacant (or - immediately, if it is already too late). The members may vote by - public acclamation for any fellow committee member, including - themselves; there is no None Of The Above option. The vote finishes - when all the members have voted or when the outcome is no longer in - doubt. The result is determined according to Concorde Vote - Counting. - 8. The Chairman can stand in for the Leader, together with the - Secretary - As detailed in §7.1(2), the Chairman of the Technical Committee and - the Project Secretary may together stand in for the Leader if there - is no Leader. - - 6.2. Composition - - 1. The Technical Committee consists of up to 8 Developers, and should - usually have at least 4 members. - 2. When there are fewer than 8 members the Technical Committee may - recommend new member(s) to the Project Leader, who may choose - (individually) to appoint them or not. - 3. When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6. - 4. When there have been 5 members or fewer for at least one week the - Project Leader may appoint new member(s) until the number of - members reaches 6, at intervals of at least one week per - appointment. - 5. If the Technical Committee and the Project Leader agree they may - remove or replace an existing member of the Technical Committee. - - 6.3. Procedure - - 1. The Technical Committee uses the Standard Resolution Procedure. - A draft resolution or amendment may be proposed by any member of - the Technical Committee. There is no minimum discussion period; the - voting period lasts for up to one week, or until the outcome is no - longer in doubt. Members may change their votes. There is a quorum - of two. - 2. Details regarding voting - The Chairman has a casting vote. When the Technical Committee votes - whether to override a Developer who also happens to be a member of - the Committee, that member may not vote (unless they are the - Chairman, in which case they may use only their casting vote). - 3. Public discussion and decision-making. - Discussion, draft resolutions and amendments, and votes by members - of the committee, are made public on the Technical Committee public - discussion list. There is no separate secretary for the Committee. - 4. Confidentiality of appointments. - The Technical Committee may hold confidential discussions via - private email or a private mailing list or other means to discuss - appointments to the Committee. However, votes on appointments must - be public. - 5. No detailed design work. - The Technical Committee does not engage in design of new proposals - and policies. Such design work should be carried out by individuals - privately or together and discussed in ordinary technical policy - and design forums. - The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere. - Individual members of the technical committee may of course - participate on their own behalf in any aspect of design and policy - work. - 6. Technical Committee makes decisions only as last resort. - The Technical Committee does not make a technical decision until - efforts to resolve it via consensus have been tried and failed, - unless it has been asked to make a decision by the person or body - who would normally be responsible for it. - -7. The Project Secretary - - 7.1. Powers - - The Secretary: - 1. Takes votes amongst the Developers, and determines the number and - identity of Developers, whenever this is required by the - constitution. - 2. Can stand in for the Leader, together with the Chairman of the - Technical Committee. - If there is no Project Leader then the Chairman of the Technical - Committee and the Project Secretary may by joint agreement make - decisions if they consider it imperative to do so. - 3. Adjudicates any disputes about interpretation of the constitution. - 4. May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time. - - 7.2. Appointment - - The Project Secretary is appointed by the Project Leader and the - current Project Secretary. - - If the Project Leader and the current Project Secretary cannot agree on - a new appointment they must ask the board of SPI (see §9.1.) to appoint - a Secretary. - - If there is no Project Secretary or the current Secretary is - unavailable and has not delegated authority for a decision then the - decision may be made or delegated by the Chairman of the Technical - Committee, as Acting Secretary. - - The Project Secretary's term of office is 1 year, at which point they - or another Secretary must be (re)appointed. - - 7.3. Procedure - - The Project Secretary should make decisions which are fair and - reasonable, and preferably consistent with the consensus of the - Developers. - - When acting together to stand in for an absent Project Leader the - Chairman of the Technical Committee and the Project Secretary should - make decisions only when absolutely necessary and only when consistent - with the consensus of the Developers. - -8. The Project Leader's Delegates - - 8.1. Powers - - The Project Leader's Delegates: - 1. have powers delegated to them by the Project Leader; - 2. may make certain decisions which the Leader may not make directly, - including approving or expelling Developers or designating people - as Developers who do not maintain packages. This is to avoid - concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader. - - 8.2. Appointment - - The Delegates are appointed by the Project Leader and may be replaced - by the Leader at the Leader's discretion. The Project Leader may not - make the position as a Delegate conditional on particular decisions by - the Delegate, nor may they override a decision made by a Delegate once - made. - - 8.3. Procedure - - Delegates may make decisions as they see fit, but should attempt to - implement good technical decisions and/or follow consensus opinion. - -9. Software in the Public Interest - - SPI and Debian are separate organisations who share some goals. Debian - is grateful for the legal support framework offered by SPI. Debian's - Developers are currently members of SPI by virtue of their status as - Developers. - - 9.1. Authority - - 1. SPI has no authority regarding Debian's technical or nontechnical - decisions, except that no decision by Debian with respect to any - property held by SPI shall require SPI to act outside its legal - authority, and that Debian's constitution may occasionally use SPI - as a decision body of last resort. - 2. Debian claims no authority over SPI other than that over the use of - certain of SPI's property, as described below, though Debian - Developers may be granted authority within SPI by SPI's rules. - 3. Debian Developers are not agents or employees of SPI, or of each - other or of persons in authority in the Debian Project. A person - acting as a Developer does so as an individual, on their own - behalf. - - 9.2. Management of property for purposes related to Debian - - Since Debian has no authority to hold money or property, any donations - for the Debian Project must be made to SPI, which manages such affairs. - - SPI have made the following undertakings: - 1. SPI will hold money, trademarks and other tangible and intangible - property and manage other affairs for purposes related to Debian. - 2. Such property will be accounted for separately and held in trust - for those purposes, decided on by Debian and SPI according to this - section. - 3. SPI will not dispose of or use property held in trust for Debian - without approval from Debian, which may be granted by the Project - Leader or by General Resolution of the Developers. - 4. SPI will consider using or disposing of property held in trust for - Debian when asked to do so by the Project Leader. - 5. SPI will use or dispose of property held in trust for Debian when - asked to do so by a General Resolution of the Developers, provided - that this is compatible with SPI's legal authority. - 6. SPI will notify the Developers by electronic mail to a Debian - Project mailing list when it uses or disposes of property held in - trust for Debian. - -A. Standard Resolution Procedure - - These rules apply to communal decision-making by committees and - plebiscites, where stated above. - - A.1. Proposal - - The formal procedure begins when a draft resolution is proposed and - sponsored, as required. - - A.1. Discussion and Amendment - - 1. Following the proposal, the resolution may be discussed. Amendments - may be made formal by being proposed and sponsored according to the - requirements for a new resolution, or directly by the proposer of - the original resolution. - 2. A formal amendment may be accepted by the resolution's proposer, in - which case the formal resolution draft is immediately changed to - match. - 3. If a formal amendment is not accepted, or one of the sponsors of - the resolution does not agree with the acceptance by the proposer - of a formal amendment, the amendment remains as an amendment and - will be voted on. - 4. If an amendment accepted by the original proposer is not to the - liking of others, they may propose another amendment to reverse the - earlier change (again, they must meet the requirements for proposer - and sponsor(s).) - 5. The proposer of a resolution may suggest changes to the wordings of - amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals. - 6. The proposer of a resolution may make changes to correct minor - errors (for example, typographical errors or inconsistencies) or - changes which do not alter the meaning, providing noone objects - within 24 hours. In this case the minimum discussion period is not - restarted. - - A.2. Calling for a vote - - 1. The proposer or a sponsor of a motion or an amendment may call for - a vote, providing that the minimum discussion period (if any) has - elapsed. - 2. The proposer or a sponsor of a motion may call for a vote on any or - all of the amendments individually or together; the proposer or - sponsor of an amendment may call for a vote only on that amendment - and related amendments. - 3. The person who calls for a vote states what they believe the - wordings of the resolution and any relevant amendments are, and - consequently what form the ballot should take. However, the final - decision on the form of ballot(s) is the Secretary's - see 7.1(1), - 7.1(3) and A.3(6). - 4. The minimum discussion period is counted from the time the last - formal amendment was accepted, or the last related formal amendment - was accepted if an amendment is being voted on, or since the whole - resolution was proposed if no amendments have been proposed and - accepted. - - A.3. Voting procedure - - 1. Each independent set of related amendments is voted on in a - separate ballot. Each such ballot has as options all the sensible - combinations of amendments and options, and an option Further - Discussion. If Further Discussion wins then the entire resolution - procedure is set back to the start of the discussion period. No - quorum is required for an amendment. - 2. When the final form of the resolution has been determined it is - voted on in a final ballot, in which the options are Yes, No and - Further Discussion. If Further Discussion wins then the entire - procedure is set back to the start of the discussion period. - 3. The vote taker (if there is one) or the voters (if voting is done - by public pronouncement) may arrange for these ballots to be held - simultaneously, even (for example) using a single voting message. - If amendment ballot(s) and the final ballot are combined in this - way then it must be possible for a voter to vote differently in the - final ballot for each of the possible forms of the final draft - resolution. - 4. Votes may be cast during the voting period, as specified elsewhere. - If the voting period can end if the outcome is no longer in doubt, - the possibility that voters may change their votes is not - considered. - 5. The votes are counted according to the Concorde Vote Counting. If a - quorum is required then the default option is Further Discussion. - 6. In cases of doubt the Project Secretary shall decide on matters of - procedure (for example, whether particular amendments should be - considered independent or not). - - A.4. Withdrawing resolutions or unaccepted amendments - - The proposer of a resolution or unaccepted amendment may withdraw it. - In this case new proposers may come forward keep it alive, in which - case the first person to do so becomes the new proposer and any others - become sponsors if they aren't sponsors already. - - A sponsor of a resolution or amendment (unless it has been accepted) - may withdraw. - - If the withdrawal of the proposer and/or sponsors means that a - resolution has no proposer or not enough sponsors it will not be voted - on unless this is rectified before the resolution expires. - - A.5. Expiry - - If a proposed resolution has not been discussed, amended, voted on or - otherwise dealt with for 4 weeks then it is considered to have been - withdrawn. - - A.6. Concorde Vote Counting - - 1. This is used to determine the winner amongst a list of options. - Each ballot paper gives a ranking of the voter's preferred options. - (The ranking need not be complete.) - 2. Option A is said to Dominate option B if strictly more ballots - prefer A to B than prefer B to A. - 3. All options which are Dominated by at least one other option are - discarded, and references to them in ballot papers will be ignored. - 4. If there is any option which Dominates all others then that is the - winner. - 5. If there is now more than one option remaining Single Transferrable - Vote will be applied to choose amongst those remaining: - + The number of first preferences for each option is counted, - and if any option has more than half it is the winner. - + Otherwise the option with the lowest number of first - preferences is eliminated and its votes redistributed - according to the second preferences. - + This elimination procedure is repeated, moving down ballot - papers to 2nd, 3rd, 4th, etc. preferences as required, until - one option gets more than half of the "first" preferences. - 6. In the case of ties the elector with a casting vote will decide. - The casting vote does not count as a normal vote; however that - elector will usually also get a normal vote. - 7. If a supermajority is required the number of Yes votes in the final - ballot is reduced by an appropriate factor. Strictly speaking, for - a supermajority of F:A, the number of ballots which prefer Yes to X - (when considering whether Yes Dominates X or X Dominates Yes) or - the number of ballots whose first (remaining) preference is Yes - (when doing STV comparisons for winner and elimination purposes) is - multiplied by a factor A/F before the comparison is done. This - means that a 2:1 vote, for example, means twice as many people - voted for as against; abstentions are not counted. - 8. If a quorum is required, there must be at least that many votes - which prefer the winning option to the default option. If there are - not then the default option wins after all. For votes requiring a - supermajority, the actual number of Yes votes is used when checking - whether the quorum has been reached. - - When the Standard Resolution Procedure is to be used, the text which - refers to it must specify what is sufficient to have a draft resolution - proposed and/or sponsored, what the minimum discussion period is, and - what the voting period is. It must also specify any supermajority - and/or the quorum (and default option) to be used. - -B. Use of language and typography - - The present indicative ("is", for example) means that the statement is - a rule in this constitution. "May" or "can" indicates that the person - or body has discretion. "Should" means that it would be considered a - good thing if the sentence were obeyed, but it is not binding. Text - marked as a citation, such as this, is rationale and does not form part - of the constitution. It may be used only to aid interpretation in cases - of doubt. diff -Nru doc-debian-4.0.2ubuntu1/doc/constitution.1.0.wml doc-debian-6.1ubuntu1/doc/constitution.1.0.wml --- doc-debian-4.0.2ubuntu1/doc/constitution.1.0.wml 2010-01-11 21:03:52.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/constitution.1.0.wml 2012-10-20 04:09:43.000000000 +0100 @@ -6,7 +6,7 @@ 2003, which is itself superseded by version 1.2, ratified on October 29th, 2003. Version 1.2 was again superseded by version 1.3 ratified on September 24th, 2006. -That was superceded by the current version +That was superseded by the current version ratified on October 7th, 2007.

      diff -Nru doc-debian-4.0.2ubuntu1/doc/constitution.1.1.txt doc-debian-6.1ubuntu1/doc/constitution.1.1.txt --- doc-debian-4.0.2ubuntu1/doc/constitution.1.1.txt 2010-01-11 21:06:50.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/constitution.1.1.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,591 +0,0 @@ - Historical version of the Constitution for the Debian Project (v1.1) - - Version 1.1 ratified on June 21st, 2003. Supersedes Version 1.0 - ratified on December 2nd, 1998. Superseded by version 1.2, ratified on - October 29th, 2003, which was again superseded by version 1.3 ratified - on September 24th, 2006. That was superceded by the current version, - 1.4 ratified on October 7th, 2007. - -1. Introduction - - The Debian Project is an association of individuals who have made - common cause to create a free operating system. - - This document describes the organisational structure for formal - decision-making in the Project. It does not describe the goals of the - Project or how it achieves them, or contain any policies except those - directly related to the decision-making process. - -2. Decision-making bodies and individuals - - Each decision in the Project is made by one or more of the following: - 1. The Developers, by way of General Resolution or an election; - 2. The Project Leader; - 3. The Technical Committee and/or its Chairman; - 4. The individual Developer working on a particular task; - 5. Delegates appointed by the Project Leader for specific tasks; - 6. The Project Secretary. - - Most of the remainder of this document will outline the powers of these - bodies, their composition and appointment, and the procedure for their - decision-making. The powers of a person or body may be subject to - review and/or limitation by others; in this case the reviewing body or - person's entry will state this. In the list above, a person or body is - usually listed before any people or bodies whose decisions they can - overrule or who they (help) appoint - but not everyone listed earlier - can overrule everyone listed later. - - 2.1. General rules - - 1. Nothing in this constitution imposes an obligation on anyone to do - work for the Project. A person who does not want to do a task which - has been delegated or assigned to them does not need to do it. - However, they must not actively work against these rules and - decisions properly made under them. - 2. A person may hold several posts, except that the Project Leader, - Project Secretary and the Chairman of the Technical Committee must - be distinct, and that the Leader cannot appoint themselves as their - own Delegate. - 3. A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly. - -3. Individual Developers - - 3.1. Powers - - An individual Developer may - 1. make any technical or nontechnical decision with regard to their - own work; - 2. propose or sponsor draft General Resolutions; - 3. propose themselves as a Project Leader candidate in elections; - 4. vote on General Resolutions and in Leadership elections. - - 3.2. Composition and appointment - - 1. Developers are volunteers who agree to further the aims of the - Project insofar as they participate in it, and who maintain - package(s) for the Project or do other work which the Project - Leader's Delegate(s) consider worthwhile. - 2. The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. If the Developers feel - that the Delegates are abusing their authority they can of course - override the decision by way of General Resolution - see §4.1(3), - §4.2. - - 3.3. Procedure - - Developers may make these decisions as they see fit. - -4. The Developers by way of General Resolution or election - - 4.1. Powers - - Together, the Developers may: - 1. Appoint or recall the Project Leader. - 2. Amend this constitution, provided they agree with a 3:1 majority. - 3. Override any decision by the Project Leader or a Delegate. - 4. Override any decision by the Technical Committee, provided they - agree with a 2:1 majority. - 5. Issue nontechnical policy documents and statements. - These include documents describing the goals of the project, its - relationship with other free software entities, and nontechnical - policies such as the free software licence terms that Debian - software must meet. - They may also include position statements about issues of the day. - 6. Together with the Project Leader and SPI, make decisions about - property held in trust for purposes related to Debian. (See §9.1.) - - 4.2. Procedure - - 1. The Developers follow the Standard Resolution Procedure, below. A - resolution or amendment is introduced if proposed by any Developer - and sponsored by at least K other Developers, or if proposed by the - Project Leader or the Technical Committee. - 2. Delaying a decision by the Project Leader or their Delegate: - 1. If the Project Leader or their Delegate, or the Technical - Committee, has made a decision, then Developers can override - them by passing a resolution to do so; see §4.1(3). - 2. If such a resolution is sponsored by at least 2K Developers, - or if it is proposed by the Technical Committee, the - resolution puts the decision immediately on hold (provided - that resolution itself says so). - 3. If the original decision was to change a discussion period or - a voting period, or the resolution is to override the - Technical Committee, then only K Developers need to sponsor - the resolution to be able to put the decision immediately on - hold. - 4. If the decision is put on hold, an immediate vote is held to - determine whether the decision will stand until the full vote - on the decision is made or whether the implementation of the - original decision will be delayed until then. There is no - quorum for this immediate procedural vote. - 5. If the Project Leader (or the Delegate) withdraws the original - decision, the vote becomes moot, and is no longer conducted. - 3. Votes are taken by the Project Secretary. Votes, tallies, and - results are not revealed during the voting period; after the vote - the Project Secretary lists all the votes cast. The voting period - is 2 weeks, but may be varied by up to 1 week by the Project - Leader. - 4. The minimum discussion period is 2 weeks, but may be varied by up - to 1 week by the Project Leader. The Project Leader has a casting - vote. There is a quorum of 3Q. - 5. Proposals, sponsors, amendments, calls for votes and other formal - actions are made by announcement on a publicly-readable electronic - mailing list designated by the Project Leader's Delegate(s); any - Developer may post there. - 6. Votes are cast by email in a manner suitable to the Secretary. The - Secretary determines for each poll whether voters can change their - votes. - 7. Q is half of the square root of the number of current Developers. K - is Q or 5, whichever is the smaller. Q and K need not be integers - and are not rounded. - -5. Project Leader - - 5.1. Powers - - The Project Leader may: - 1. Appoint Delegates or delegate decisions to the Technical Committee. - The Leader may define an area of ongoing responsibility or a - specific decision and hand it over to another Developer or to the - Technical Committee. - Once a particular decision has been delegated and made the Project - Leader may not withdraw that delegation; however, they may withdraw - an ongoing delegation of particular area of responsibility. - 2. Lend authority to other Developers. - The Project Leader may make statements of support for points of - view or for other members of the project, when asked or otherwise; - these statements have force if and only if the Leader would be - empowered to make the decision in question. - 3. Make any decision which requires urgent action. - This does not apply to decisions which have only become gradually - urgent through lack of relevant action, unless there is a fixed - deadline. - 4. Make any decision for whom noone else has responsibility. - 5. Propose draft General Resolutions and amendments. - 6. Together with the Technical Committee, appoint new members to the - Committee. (See §6.2.) - 7. Use a casting vote when Developers vote. - The Project Leader also has a normal vote in such ballots. - 8. Vary the discussion period for Developers' votes (as above). - 9. Lead discussions amongst Developers. - The Project Leader should attempt to participate in discussions - amongst the Developers in a helpful way which seeks to bring the - discussion to bear on the key issues at hand. The Project Leader - should not use the Leadership position to promote their own - personal views. - 10. Together with SPI, make decisions affecting property held in trust - for purposes related to Debian. (See §9.1.) - - 5.2. Appointment - - 1. The Project Leader is elected by the Developers. - 2. The election begins nine weeks before the leadership post becomes - vacant, or (if it is too late already) immediately. - 3. For the following three weeks any Developer may nominate themselves - as a candidate Project Leader. - 4. For three weeks after that no more candidates may be nominated; - candidates should use this time for campaigning (to make their - identities and positions known). If there are no candidates at the - end of the nomination period then the nomination period is extended - for three further weeks, repeatedly if necessary. - 5. The next three weeks are the polling period during which Developers - may cast their votes. Votes in leadership elections are kept - secret, even after the election is finished. - 6. The options on the ballot will be those candidates who have - nominated themselves and have not yet withdrawn, plus None Of The - Above. If None Of The Above wins the election then the election - procedure is repeated, many times if necessary. - 7. The decision will be made using the method specified in section - §A.6 of the Standard Resolution Procedure. The quorum is the same - as for a General Resolution (§4.2) and the default option is "None - Of The Above". - 8. The Project Leader serves for one year from their election. - - 5.3. Procedure - - The Project Leader should attempt to make decisions which are - consistent with the consensus of the opinions of the Developers. - - Where practical the Project Leader should informally solicit the views - of the Developers. - - The Project Leader should avoid overemphasizing their own point of view - when making decisions in their capacity as Leader. - -6. Technical committee - - 6.1. Powers - - The Technical Committee may: - 1. Decide on any matter of technical policy. - This includes the contents of the technical policy manuals, - developers' reference materials, example packages and the behaviour - of non-experimental package building tools. (In each case the usual - maintainer of the relevant software or documentation makes - decisions initially, however; see 6.3(5).) - 2. Decide any technical matter where Developers' jurisdictions - overlap. - In cases where Developers need to implement compatible technical - policies or stances (for example, if they disagree about the - priorities of conflicting packages, or about ownership of a command - name, or about which package is responsible for a bug that both - maintainers agree is a bug, or about who should be the maintainer - for a package) the technical committee may decide the matter. - 3. Make a decision when asked to do so. - Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it. - 4. Overrule a Developer (requires a 3:1 majority). - The Technical Committee may ask a Developer to take a particular - technical course of action even if the Developer does not wish to; - this requires a 3:1 majority. For example, the Committee may - determine that a complaint made by the submitter of a bug is - justified and that the submitter's proposed solution should be - implemented. - 5. Offer advice. - The Technical Committee may make formal announcements about its - views on any matter. Individual members may of course make informal - statements about their views and about the likely views of the - committee. - 6. Together with the Project Leader, appoint new members to itself or - remove existing members. (See §6.2.) - 7. Appoint the Chairman of the Technical Committee. - The Chairman is elected by the Committee from its members. All - members of the committee are automatically nominated; the committee - votes starting one week before the post will become vacant (or - immediately, if it is already too late). The members may vote by - public acclamation for any fellow committee member, including - themselves; there is no default option. The vote finishes when all - the members have voted, or when the voting period has ended. The - result is determined using the method specified in section A.6 of - the Standard Resolution Procedure. - 8. The Chairman can stand in for the Leader, together with the - Secretary - As detailed in §7.1(2), the Chairman of the Technical Committee and - the Project Secretary may together stand in for the Leader if there - is no Leader. - - 6.2. Composition - - 1. The Technical Committee consists of up to 8 Developers, and should - usually have at least 4 members. - 2. When there are fewer than 8 members the Technical Committee may - recommend new member(s) to the Project Leader, who may choose - (individually) to appoint them or not. - 3. When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6. - 4. When there have been 5 members or fewer for at least one week the - Project Leader may appoint new member(s) until the number of - members reaches 6, at intervals of at least one week per - appointment. - 5. If the Technical Committee and the Project Leader agree they may - remove or replace an existing member of the Technical Committee. - - 6.3. Procedure - - 1. The Technical Committee uses the Standard Resolution Procedure. - A draft resolution or amendment may be proposed by any member of - the Technical Committee. There is no minimum discussion period; the - voting period lasts for up to one week, or until the outcome is no - longer in doubt. Members may change their votes. There is a quorum - of two. - 2. Details regarding voting - The Chairman has a casting vote. When the Technical Committee votes - whether to override a Developer who also happens to be a member of - the Committee, that member may not vote (unless they are the - Chairman, in which case they may use only their casting vote). - 3. Public discussion and decision-making. - Discussion, draft resolutions and amendments, and votes by members - of the committee, are made public on the Technical Committee public - discussion list. There is no separate secretary for the Committee. - 4. Confidentiality of appointments. - The Technical Committee may hold confidential discussions via - private email or a private mailing list or other means to discuss - appointments to the Committee. However, votes on appointments must - be public. - 5. No detailed design work. - The Technical Committee does not engage in design of new proposals - and policies. Such design work should be carried out by individuals - privately or together and discussed in ordinary technical policy - and design forums. - The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere. - Individual members of the technical committee may of course - participate on their own behalf in any aspect of design and policy - work. - 6. Technical Committee makes decisions only as last resort. - The Technical Committee does not make a technical decision until - efforts to resolve it via consensus have been tried and failed, - unless it has been asked to make a decision by the person or body - who would normally be responsible for it. - -7. The Project Secretary - - 7.1. Powers - - The Secretary: - 1. Takes votes amongst the Developers, and determines the number and - identity of Developers, whenever this is required by the - constitution. - 2. Can stand in for the Leader, together with the Chairman of the - Technical Committee. - If there is no Project Leader then the Chairman of the Technical - Committee and the Project Secretary may by joint agreement make - decisions if they consider it imperative to do so. - 3. Adjudicates any disputes about interpretation of the constitution. - 4. May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time. - - 7.2. Appointment - - The Project Secretary is appointed by the Project Leader and the - current Project Secretary. - - If the Project Leader and the current Project Secretary cannot agree on - a new appointment they must ask the board of SPI (see §9.1.) to appoint - a Secretary. - - If there is no Project Secretary or the current Secretary is - unavailable and has not delegated authority for a decision then the - decision may be made or delegated by the Chairman of the Technical - Committee, as Acting Secretary. - - The Project Secretary's term of office is 1 year, at which point they - or another Secretary must be (re)appointed. - - 7.3. Procedure - - The Project Secretary should make decisions which are fair and - reasonable, and preferably consistent with the consensus of the - Developers. - - When acting together to stand in for an absent Project Leader the - Chairman of the Technical Committee and the Project Secretary should - make decisions only when absolutely necessary and only when consistent - with the consensus of the Developers. - -8. The Project Leader's Delegates - - 8.1. Powers - - The Project Leader's Delegates: - 1. have powers delegated to them by the Project Leader; - 2. may make certain decisions which the Leader may not make directly, - including approving or expelling Developers or designating people - as Developers who do not maintain packages. This is to avoid - concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader. - - 8.2. Appointment - - The Delegates are appointed by the Project Leader and may be replaced - by the Leader at the Leader's discretion. The Project Leader may not - make the position as a Delegate conditional on particular decisions by - the Delegate, nor may they override a decision made by a Delegate once - made. - - 8.3. Procedure - - Delegates may make decisions as they see fit, but should attempt to - implement good technical decisions and/or follow consensus opinion. - -9. Software in the Public Interest - - SPI and Debian are separate organisations who share some goals. Debian - is grateful for the legal support framework offered by SPI. Debian's - Developers are currently members of SPI by virtue of their status as - Developers. - - 9.1. Authority - - 1. SPI has no authority regarding Debian's technical or nontechnical - decisions, except that no decision by Debian with respect to any - property held by SPI shall require SPI to act outside its legal - authority, and that Debian's constitution may occasionally use SPI - as a decision body of last resort. - 2. Debian claims no authority over SPI other than that over the use of - certain of SPI's property, as described below, though Debian - Developers may be granted authority within SPI by SPI's rules. - 3. Debian Developers are not agents or employees of SPI, or of each - other or of persons in authority in the Debian Project. A person - acting as a Developer does so as an individual, on their own - behalf. - - 9.2. Management of property for purposes related to Debian - - Since Debian has no authority to hold money or property, any donations - for the Debian Project must be made to SPI, which manages such affairs. - - SPI have made the following undertakings: - 1. SPI will hold money, trademarks and other tangible and intangible - property and manage other affairs for purposes related to Debian. - 2. Such property will be accounted for separately and held in trust - for those purposes, decided on by Debian and SPI according to this - section. - 3. SPI will not dispose of or use property held in trust for Debian - without approval from Debian, which may be granted by the Project - Leader or by General Resolution of the Developers. - 4. SPI will consider using or disposing of property held in trust for - Debian when asked to do so by the Project Leader. - 5. SPI will use or dispose of property held in trust for Debian when - asked to do so by a General Resolution of the Developers, provided - that this is compatible with SPI's legal authority. - 6. SPI will notify the Developers by electronic mail to a Debian - Project mailing list when it uses or disposes of property held in - trust for Debian. - -A. Standard Resolution Procedure - - These rules apply to communal decision-making by committees and - plebiscites, where stated above. - - A.1. Proposal - - The formal procedure begins when a draft resolution is proposed and - sponsored, as required. - - A.1. Discussion and Amendment - - 1. Following the proposal, the resolution may be discussed. Amendments - may be made formal by being proposed and sponsored according to the - requirements for a new resolution, or directly by the proposer of - the original resolution. - 2. A formal amendment may be accepted by the resolution's proposer, in - which case the formal resolution draft is immediately changed to - match. - 3. If a formal amendment is not accepted, or one of the sponsors of - the resolution does not agree with the acceptance by the proposer - of a formal amendment, the amendment remains as an amendment and - will be voted on. - 4. If an amendment accepted by the original proposer is not to the - liking of others, they may propose another amendment to reverse the - earlier change (again, they must meet the requirements for proposer - and sponsor(s).) - 5. The proposer of a resolution may suggest changes to the wordings of - amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals. - 6. The proposer of a resolution may make changes to correct minor - errors (for example, typographical errors or inconsistencies) or - changes which do not alter the meaning, providing noone objects - within 24 hours. In this case the minimum discussion period is not - restarted. - - A.2. Calling for a vote - - 1. The proposer or a sponsor of a motion or an amendment may call for - a vote, providing that the minimum discussion period (if any) has - elapsed. - 2. The proposer or any sponsor of a resolution may call for a vote on - that resolution and all related amendments. - 3. The person who calls for a vote states what they believe the - wordings of the resolution and any relevant amendments are, and - consequently what form the ballot should take. However, the final - decision on the form of ballot(s) is the Secretary's - see 7.1(1), - 7.1(3) and A.3(4). - 4. The minimum discussion period is counted from the time the last - formal amendment was accepted, or since the whole resolution was - proposed if no amendments have been proposed and accepted. - - A.3. Voting procedure - - 1. Each resolution and its related amendments is voted on in a single - ballot that includes an option for the original resolution, each - amendment, and the default option (where applicable). - 2. The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - 3. The votes are counted according to the rules in A.6. The default - option is "Further Discussion", unless specified otherwise. - 4. In cases of doubt the Project Secretary shall decide on matters of - procedure. - - A.4. Withdrawing resolutions or unaccepted amendments - - The proposer of a resolution or unaccepted amendment may withdraw it. - In this case new proposers may come forward keep it alive, in which - case the first person to do so becomes the new proposer and any others - become sponsors if they aren't sponsors already. - - A sponsor of a resolution or amendment (unless it has been accepted) - may withdraw. - - If the withdrawal of the proposer and/or sponsors means that a - resolution has no proposer or not enough sponsors it will not be voted - on unless this is rectified before the resolution expires. - - A.5. Expiry - - If a proposed resolution has not been discussed, amended, voted on or - otherwise dealt with for 4 weeks the secretary may issue a statement - that the issue is being withdrawn. If none of the sponsors of any of - the proposals object within a week, the issue is withdrawn. - - The secretary may also include suggestions on how to proceed, if - appropriate. - - A.6. Vote Counting - - 1. Each voter's ballot ranks the options being voted on. Not all - options need be ranked. Ranked options are considered preferred to - all unranked options. Voters may rank options equally. Unranked - options are considered to be ranked equally with one another. - Details of how ballots may be filled out will be included in the - Call For Votes. - 2. If the ballot has a quorum requirement R any options other than the - default option which do not receive at least R votes ranking that - option above the default option are dropped from consideration. - 3. Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - 1. Given two options A and B, V(A,B) is the number of voters who - prefer option A over option B. - 2. An option A defeats the default option D by a majority ratio - N, if V(A,D) is strictly greater than N * V(D,A). - 3. If a supermajority of S:1 is required for A, its majority - ratio is S; otherwise, its majority ratio is 1. - 4. From the list of undropped options, we generate a list of pairwise - defeats. - 1. An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - 5. From the list of [undropped] pairwise defeats, we generate a set of - transitive defeats. - 1. An option A transitively defeats an option C if A defeats C or - if there is some other option B where A defeats B AND B - transitively defeats C. - 6. We construct the Schwartz set from the set of transitive defeats. - 1. An option A is in the Schwartz set if for all options B, - either A transitively defeats B, or B does not transitively - defeat A. - 7. If there are defeats between options in the Schwartz set, we drop - the weakest such defeats from the list of pairwise defeats, and - return to step 5. - 1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less - than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is - equal to V(B,Y) and V(X,A) is greater than V(Y,B). - 2. A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - 8. If there are no defeats within the Schwartz set, then the winner is - chosen from the options in the Schwartz set. If there is only one - such option, it is the winner. If there are multiple options, the - elector with the casting vote chooses which of those options wins. - - Note: Options which the voters rank above the default option are - options they find acceptable. Options ranked below the default options - are options they find unacceptable. - - When the Standard Resolution Procedure is to be used, the text which - refers to it must specify what is sufficient to have a draft resolution - proposed and/or sponsored, what the minimum discussion period is, and - what the voting period is. It must also specify any supermajority - and/or the quorum (and default option) to be used. - -B. Use of language and typography - - The present indicative ("is", for example) means that the statement is - a rule in this constitution. "May" or "can" indicates that the person - or body has discretion. "Should" means that it would be considered a - good thing if the sentence were obeyed, but it is not binding. Text - marked as a citation, such as this, is rationale and does not form part - of the constitution. It may be used only to aid interpretation in cases - of doubt. diff -Nru doc-debian-4.0.2ubuntu1/doc/constitution.1.1.wml doc-debian-6.1ubuntu1/doc/constitution.1.1.wml --- doc-debian-4.0.2ubuntu1/doc/constitution.1.1.wml 2010-01-11 21:06:50.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/constitution.1.1.wml 2012-10-20 04:09:43.000000000 +0100 @@ -6,7 +6,7 @@ 1998. Superseded by version 1.2, ratified on October 29th, 2003, which was again superseded by version 1.3 ratified on September 24th, 2006. -That was superceded by the current version, 1.4 +That was superseded by the current version, 1.4 ratified on October 7th, 2007.

      diff -Nru doc-debian-4.0.2ubuntu1/doc/constitution.1.2.txt doc-debian-6.1ubuntu1/doc/constitution.1.2.txt --- doc-debian-4.0.2ubuntu1/doc/constitution.1.2.txt 2010-01-11 21:06:51.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/constitution.1.2.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,600 +0,0 @@ - Historical version of the Constitution for the Debian Project (v1.2) - - Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 - ratified on June 21st, 2003, which itself supersedes Version 1.0 - ratified on December 2nd, 1998. Superseded by version 1.3, ratified on - September 24th, 2006. That was superceded by the current version, 1.4 - ratified on October 7th, 2007. - -1. Introduction - - The Debian Project is an association of individuals who have made - common cause to create a free operating system. - - This document describes the organisational structure for formal - decision-making in the Project. It does not describe the goals of the - Project or how it achieves them, or contain any policies except those - directly related to the decision-making process. - -2. Decision-making bodies and individuals - - Each decision in the Project is made by one or more of the following: - 1. The Developers, by way of General Resolution or an election; - 2. The Project Leader; - 3. The Technical Committee and/or its Chairman; - 4. The individual Developer working on a particular task; - 5. Delegates appointed by the Project Leader for specific tasks; - 6. The Project Secretary. - - Most of the remainder of this document will outline the powers of these - bodies, their composition and appointment, and the procedure for their - decision-making. The powers of a person or body may be subject to - review and/or limitation by others; in this case the reviewing body or - person's entry will state this. In the list above, a person or body is - usually listed before any people or bodies whose decisions they can - overrule or who they (help) appoint - but not everyone listed earlier - can overrule everyone listed later. - - 2.1. General rules - - 1. Nothing in this constitution imposes an obligation on anyone to do - work for the Project. A person who does not want to do a task which - has been delegated or assigned to them does not need to do it. - However, they must not actively work against these rules and - decisions properly made under them. - 2. A person may hold several posts, except that the Project Leader, - Project Secretary and the Chairman of the Technical Committee must - be distinct, and that the Leader cannot appoint themselves as their - own Delegate. - 3. A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly. - -3. Individual Developers - - 3.1. Powers - - An individual Developer may - 1. make any technical or nontechnical decision with regard to their - own work; - 2. propose or sponsor draft General Resolutions; - 3. propose themselves as a Project Leader candidate in elections; - 4. vote on General Resolutions and in Leadership elections. - - 3.2. Composition and appointment - - 1. Developers are volunteers who agree to further the aims of the - Project insofar as they participate in it, and who maintain - package(s) for the Project or do other work which the Project - Leader's Delegate(s) consider worthwhile. - 2. The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. If the Developers feel - that the Delegates are abusing their authority they can of course - override the decision by way of General Resolution - see §4.1(3), - §4.2. - - 3.3. Procedure - - Developers may make these decisions as they see fit. - -4. The Developers by way of General Resolution or election - - 4.1. Powers - - Together, the Developers may: - 1. Appoint or recall the Project Leader. - 2. Amend this constitution, provided they agree with a 3:1 majority. - 3. Override any decision by the Project Leader or a Delegate. - 4. Override any decision by the Technical Committee, provided they - agree with a 2:1 majority. - 5. Issue, supersede and withdraw nontechnical policy documents and - statements. - These include documents describing the goals of the project, its - relationship with other free software entities, and nontechnical - policies such as the free software licence terms that Debian - software must meet. - They may also include position statements about issues of the day. - 1. A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes. - 2. The Foundation Documents are the works entitled "Debian Social - Contract" and "Debian Free Software Guidelines". - 3. A Foundation Document requires a 3:1 majority for its - supersession. New Foundation Documents are issued and existing - ones withdrawn by amending the list of Foundation Documents in - this constitution. - 6. Together with the Project Leader and SPI, make decisions about - property held in trust for purposes related to Debian. (See §9.1.) - - 4.2. Procedure - - 1. The Developers follow the Standard Resolution Procedure, below. A - resolution or amendment is introduced if proposed by any Developer - and sponsored by at least K other Developers, or if proposed by the - Project Leader or the Technical Committee. - 2. Delaying a decision by the Project Leader or their Delegate: - 1. If the Project Leader or their Delegate, or the Technical - Committee, has made a decision, then Developers can override - them by passing a resolution to do so; see §4.1(3). - 2. If such a resolution is sponsored by at least 2K Developers, - or if it is proposed by the Technical Committee, the - resolution puts the decision immediately on hold (provided - that resolution itself says so). - 3. If the original decision was to change a discussion period or - a voting period, or the resolution is to override the - Technical Committee, then only K Developers need to sponsor - the resolution to be able to put the decision immediately on - hold. - 4. If the decision is put on hold, an immediate vote is held to - determine whether the decision will stand until the full vote - on the decision is made or whether the implementation of the - original decision will be delayed until then. There is no - quorum for this immediate procedural vote. - 5. If the Project Leader (or the Delegate) withdraws the original - decision, the vote becomes moot, and is no longer conducted. - 3. Votes are taken by the Project Secretary. Votes, tallies, and - results are not revealed during the voting period; after the vote - the Project Secretary lists all the votes cast. The voting period - is 2 weeks, but may be varied by up to 1 week by the Project - Leader. - 4. The minimum discussion period is 2 weeks, but may be varied by up - to 1 week by the Project Leader. The Project Leader has a casting - vote. There is a quorum of 3Q. - 5. Proposals, sponsors, amendments, calls for votes and other formal - actions are made by announcement on a publicly-readable electronic - mailing list designated by the Project Leader's Delegate(s); any - Developer may post there. - 6. Votes are cast by email in a manner suitable to the Secretary. The - Secretary determines for each poll whether voters can change their - votes. - 7. Q is half of the square root of the number of current Developers. K - is Q or 5, whichever is the smaller. Q and K need not be integers - and are not rounded. - -5. Project Leader - - 5.1. Powers - - The Project Leader may: - 1. Appoint Delegates or delegate decisions to the Technical Committee. - The Leader may define an area of ongoing responsibility or a - specific decision and hand it over to another Developer or to the - Technical Committee. - Once a particular decision has been delegated and made the Project - Leader may not withdraw that delegation; however, they may withdraw - an ongoing delegation of particular area of responsibility. - 2. Lend authority to other Developers. - The Project Leader may make statements of support for points of - view or for other members of the project, when asked or otherwise; - these statements have force if and only if the Leader would be - empowered to make the decision in question. - 3. Make any decision which requires urgent action. - This does not apply to decisions which have only become gradually - urgent through lack of relevant action, unless there is a fixed - deadline. - 4. Make any decision for whom noone else has responsibility. - 5. Propose draft General Resolutions and amendments. - 6. Together with the Technical Committee, appoint new members to the - Committee. (See §6.2.) - 7. Use a casting vote when Developers vote. - The Project Leader also has a normal vote in such ballots. - 8. Vary the discussion period for Developers' votes (as above). - 9. Lead discussions amongst Developers. - The Project Leader should attempt to participate in discussions - amongst the Developers in a helpful way which seeks to bring the - discussion to bear on the key issues at hand. The Project Leader - should not use the Leadership position to promote their own - personal views. - 10. Together with SPI, make decisions affecting property held in trust - for purposes related to Debian. (See §9.1.) - - 5.2. Appointment - - 1. The Project Leader is elected by the Developers. - 2. The election begins nine weeks before the leadership post becomes - vacant, or (if it is too late already) immediately. - 3. For the following three weeks any Developer may nominate themselves - as a candidate Project Leader. - 4. For three weeks after that no more candidates may be nominated; - candidates should use this time for campaigning (to make their - identities and positions known). If there are no candidates at the - end of the nomination period then the nomination period is extended - for three further weeks, repeatedly if necessary. - 5. The next three weeks are the polling period during which Developers - may cast their votes. Votes in leadership elections are kept - secret, even after the election is finished. - 6. The options on the ballot will be those candidates who have - nominated themselves and have not yet withdrawn, plus None Of The - Above. If None Of The Above wins the election then the election - procedure is repeated, many times if necessary. - 7. The decision will be made using the method specified in section - §A.6 of the Standard Resolution Procedure. The quorum is the same - as for a General Resolution (§4.2) and the default option is "None - Of The Above". - 8. The Project Leader serves for one year from their election. - - 5.3. Procedure - - The Project Leader should attempt to make decisions which are - consistent with the consensus of the opinions of the Developers. - - Where practical the Project Leader should informally solicit the views - of the Developers. - - The Project Leader should avoid overemphasizing their own point of view - when making decisions in their capacity as Leader. - -6. Technical committee - - 6.1. Powers - - The Technical Committee may: - 1. Decide on any matter of technical policy. - This includes the contents of the technical policy manuals, - developers' reference materials, example packages and the behaviour - of non-experimental package building tools. (In each case the usual - maintainer of the relevant software or documentation makes - decisions initially, however; see 6.3(5).) - 2. Decide any technical matter where Developers' jurisdictions - overlap. - In cases where Developers need to implement compatible technical - policies or stances (for example, if they disagree about the - priorities of conflicting packages, or about ownership of a command - name, or about which package is responsible for a bug that both - maintainers agree is a bug, or about who should be the maintainer - for a package) the technical committee may decide the matter. - 3. Make a decision when asked to do so. - Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it. - 4. Overrule a Developer (requires a 3:1 majority). - The Technical Committee may ask a Developer to take a particular - technical course of action even if the Developer does not wish to; - this requires a 3:1 majority. For example, the Committee may - determine that a complaint made by the submitter of a bug is - justified and that the submitter's proposed solution should be - implemented. - 5. Offer advice. - The Technical Committee may make formal announcements about its - views on any matter. Individual members may of course make informal - statements about their views and about the likely views of the - committee. - 6. Together with the Project Leader, appoint new members to itself or - remove existing members. (See §6.2.) - 7. Appoint the Chairman of the Technical Committee. - The Chairman is elected by the Committee from its members. All - members of the committee are automatically nominated; the committee - votes starting one week before the post will become vacant (or - immediately, if it is already too late). The members may vote by - public acclamation for any fellow committee member, including - themselves; there is no default option. The vote finishes when all - the members have voted, or when the voting period has ended. The - result is determined using the method specified in section A.6 of - the Standard Resolution Procedure. - 8. The Chairman can stand in for the Leader, together with the - Secretary - As detailed in §7.1(2), the Chairman of the Technical Committee and - the Project Secretary may together stand in for the Leader if there - is no Leader. - - 6.2. Composition - - 1. The Technical Committee consists of up to 8 Developers, and should - usually have at least 4 members. - 2. When there are fewer than 8 members the Technical Committee may - recommend new member(s) to the Project Leader, who may choose - (individually) to appoint them or not. - 3. When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6. - 4. When there have been 5 members or fewer for at least one week the - Project Leader may appoint new member(s) until the number of - members reaches 6, at intervals of at least one week per - appointment. - 5. If the Technical Committee and the Project Leader agree they may - remove or replace an existing member of the Technical Committee. - - 6.3. Procedure - - 1. The Technical Committee uses the Standard Resolution Procedure. - A draft resolution or amendment may be proposed by any member of - the Technical Committee. There is no minimum discussion period; the - voting period lasts for up to one week, or until the outcome is no - longer in doubt. Members may change their votes. There is a quorum - of two. - 2. Details regarding voting - The Chairman has a casting vote. When the Technical Committee votes - whether to override a Developer who also happens to be a member of - the Committee, that member may not vote (unless they are the - Chairman, in which case they may use only their casting vote). - 3. Public discussion and decision-making. - Discussion, draft resolutions and amendments, and votes by members - of the committee, are made public on the Technical Committee public - discussion list. There is no separate secretary for the Committee. - 4. Confidentiality of appointments. - The Technical Committee may hold confidential discussions via - private email or a private mailing list or other means to discuss - appointments to the Committee. However, votes on appointments must - be public. - 5. No detailed design work. - The Technical Committee does not engage in design of new proposals - and policies. Such design work should be carried out by individuals - privately or together and discussed in ordinary technical policy - and design forums. - The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere. - Individual members of the technical committee may of course - participate on their own behalf in any aspect of design and policy - work. - 6. Technical Committee makes decisions only as last resort. - The Technical Committee does not make a technical decision until - efforts to resolve it via consensus have been tried and failed, - unless it has been asked to make a decision by the person or body - who would normally be responsible for it. - -7. The Project Secretary - - 7.1. Powers - - The Secretary: - 1. Takes votes amongst the Developers, and determines the number and - identity of Developers, whenever this is required by the - constitution. - 2. Can stand in for the Leader, together with the Chairman of the - Technical Committee. - If there is no Project Leader then the Chairman of the Technical - Committee and the Project Secretary may by joint agreement make - decisions if they consider it imperative to do so. - 3. Adjudicates any disputes about interpretation of the constitution. - 4. May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time. - - 7.2. Appointment - - The Project Secretary is appointed by the Project Leader and the - current Project Secretary. - - If the Project Leader and the current Project Secretary cannot agree on - a new appointment they must ask the board of SPI (see §9.1.) to appoint - a Secretary. - - If there is no Project Secretary or the current Secretary is - unavailable and has not delegated authority for a decision then the - decision may be made or delegated by the Chairman of the Technical - Committee, as Acting Secretary. - - The Project Secretary's term of office is 1 year, at which point they - or another Secretary must be (re)appointed. - - 7.3. Procedure - - The Project Secretary should make decisions which are fair and - reasonable, and preferably consistent with the consensus of the - Developers. - - When acting together to stand in for an absent Project Leader the - Chairman of the Technical Committee and the Project Secretary should - make decisions only when absolutely necessary and only when consistent - with the consensus of the Developers. - -8. The Project Leader's Delegates - - 8.1. Powers - - The Project Leader's Delegates: - 1. have powers delegated to them by the Project Leader; - 2. may make certain decisions which the Leader may not make directly, - including approving or expelling Developers or designating people - as Developers who do not maintain packages. This is to avoid - concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader. - - 8.2. Appointment - - The Delegates are appointed by the Project Leader and may be replaced - by the Leader at the Leader's discretion. The Project Leader may not - make the position as a Delegate conditional on particular decisions by - the Delegate, nor may they override a decision made by a Delegate once - made. - - 8.3. Procedure - - Delegates may make decisions as they see fit, but should attempt to - implement good technical decisions and/or follow consensus opinion. - -9. Software in the Public Interest - - SPI and Debian are separate organisations who share some goals. Debian - is grateful for the legal support framework offered by SPI. Debian's - Developers are currently members of SPI by virtue of their status as - Developers. - - 9.1. Authority - - 1. SPI has no authority regarding Debian's technical or nontechnical - decisions, except that no decision by Debian with respect to any - property held by SPI shall require SPI to act outside its legal - authority, and that Debian's constitution may occasionally use SPI - as a decision body of last resort. - 2. Debian claims no authority over SPI other than that over the use of - certain of SPI's property, as described below, though Debian - Developers may be granted authority within SPI by SPI's rules. - 3. Debian Developers are not agents or employees of SPI, or of each - other or of persons in authority in the Debian Project. A person - acting as a Developer does so as an individual, on their own - behalf. - - 9.2. Management of property for purposes related to Debian - - Since Debian has no authority to hold money or property, any donations - for the Debian Project must be made to SPI, which manages such affairs. - - SPI have made the following undertakings: - 1. SPI will hold money, trademarks and other tangible and intangible - property and manage other affairs for purposes related to Debian. - 2. Such property will be accounted for separately and held in trust - for those purposes, decided on by Debian and SPI according to this - section. - 3. SPI will not dispose of or use property held in trust for Debian - without approval from Debian, which may be granted by the Project - Leader or by General Resolution of the Developers. - 4. SPI will consider using or disposing of property held in trust for - Debian when asked to do so by the Project Leader. - 5. SPI will use or dispose of property held in trust for Debian when - asked to do so by a General Resolution of the Developers, provided - that this is compatible with SPI's legal authority. - 6. SPI will notify the Developers by electronic mail to a Debian - Project mailing list when it uses or disposes of property held in - trust for Debian. - -A. Standard Resolution Procedure - - These rules apply to communal decision-making by committees and - plebiscites, where stated above. - - A.1. Proposal - - The formal procedure begins when a draft resolution is proposed and - sponsored, as required. - - A.1. Discussion and Amendment - - 1. Following the proposal, the resolution may be discussed. Amendments - may be made formal by being proposed and sponsored according to the - requirements for a new resolution, or directly by the proposer of - the original resolution. - 2. A formal amendment may be accepted by the resolution's proposer, in - which case the formal resolution draft is immediately changed to - match. - 3. If a formal amendment is not accepted, or one of the sponsors of - the resolution does not agree with the acceptance by the proposer - of a formal amendment, the amendment remains as an amendment and - will be voted on. - 4. If an amendment accepted by the original proposer is not to the - liking of others, they may propose another amendment to reverse the - earlier change (again, they must meet the requirements for proposer - and sponsor(s).) - 5. The proposer of a resolution may suggest changes to the wordings of - amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals. - 6. The proposer of a resolution may make changes to correct minor - errors (for example, typographical errors or inconsistencies) or - changes which do not alter the meaning, providing noone objects - within 24 hours. In this case the minimum discussion period is not - restarted. - - A.2. Calling for a vote - - 1. The proposer or a sponsor of a motion or an amendment may call for - a vote, providing that the minimum discussion period (if any) has - elapsed. - 2. The proposer or any sponsor of a resolution may call for a vote on - that resolution and all related amendments. - 3. The person who calls for a vote states what they believe the - wordings of the resolution and any relevant amendments are, and - consequently what form the ballot should take. However, the final - decision on the form of ballot(s) is the Secretary's - see 7.1(1), - 7.1(3) and A.3(4). - 4. The minimum discussion period is counted from the time the last - formal amendment was accepted, or since the whole resolution was - proposed if no amendments have been proposed and accepted. - - A.3. Voting procedure - - 1. Each resolution and its related amendments is voted on in a single - ballot that includes an option for the original resolution, each - amendment, and the default option (where applicable). - 2. The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - 3. The votes are counted according to the rules in A.6. The default - option is "Further Discussion", unless specified otherwise. - 4. In cases of doubt the Project Secretary shall decide on matters of - procedure. - - A.4. Withdrawing resolutions or unaccepted amendments - - The proposer of a resolution or unaccepted amendment may withdraw it. - In this case new proposers may come forward keep it alive, in which - case the first person to do so becomes the new proposer and any others - become sponsors if they aren't sponsors already. - - A sponsor of a resolution or amendment (unless it has been accepted) - may withdraw. - - If the withdrawal of the proposer and/or sponsors means that a - resolution has no proposer or not enough sponsors it will not be voted - on unless this is rectified before the resolution expires. - - A.5. Expiry - - If a proposed resolution has not been discussed, amended, voted on or - otherwise dealt with for 4 weeks the secretary may issue a statement - that the issue is being withdrawn. If none of the sponsors of any of - the proposals object within a week, the issue is withdrawn. - - The secretary may also include suggestions on how to proceed, if - appropriate. - - A.6. Vote Counting - - 1. Each voter's ballot ranks the options being voted on. Not all - options need be ranked. Ranked options are considered preferred to - all unranked options. Voters may rank options equally. Unranked - options are considered to be ranked equally with one another. - Details of how ballots may be filled out will be included in the - Call For Votes. - 2. If the ballot has a quorum requirement R any options other than the - default option which do not receive at least R votes ranking that - option above the default option are dropped from consideration. - 3. Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - 1. Given two options A and B, V(A,B) is the number of voters who - prefer option A over option B. - 2. An option A defeats the default option D by a majority ratio - N, if V(A,D) is strictly greater than N * V(D,A). - 3. If a supermajority of S:1 is required for A, its majority - ratio is S; otherwise, its majority ratio is 1. - 4. From the list of undropped options, we generate a list of pairwise - defeats. - 1. An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - 5. From the list of [undropped] pairwise defeats, we generate a set of - transitive defeats. - 1. An option A transitively defeats an option C if A defeats C or - if there is some other option B where A defeats B AND B - transitively defeats C. - 6. We construct the Schwartz set from the set of transitive defeats. - 1. An option A is in the Schwartz set if for all options B, - either A transitively defeats B, or B does not transitively - defeat A. - 7. If there are defeats between options in the Schwartz set, we drop - the weakest such defeats from the list of pairwise defeats, and - return to step 5. - 1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less - than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is - equal to V(B,Y) and V(X,A) is greater than V(Y,B). - 2. A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - 8. If there are no defeats within the Schwartz set, then the winner is - chosen from the options in the Schwartz set. If there is only one - such option, it is the winner. If there are multiple options, the - elector with the casting vote chooses which of those options wins. - - Note: Options which the voters rank above the default option are - options they find acceptable. Options ranked below the default options - are options they find unacceptable. - - When the Standard Resolution Procedure is to be used, the text which - refers to it must specify what is sufficient to have a draft resolution - proposed and/or sponsored, what the minimum discussion period is, and - what the voting period is. It must also specify any supermajority - and/or the quorum (and default option) to be used. - -B. Use of language and typography - - The present indicative ("is", for example) means that the statement is - a rule in this constitution. "ay" or "can" indicates that the person or - body has discretion. "Should" means that it would be considered a good - thing if the sentence were obeyed, but it is not binding. Text marked - as a citation, such as this, is rationale and does not form part of the - constitution. It may be used only to aid interpretation in cases of - doubt. diff -Nru doc-debian-4.0.2ubuntu1/doc/constitution.1.2.wml doc-debian-6.1ubuntu1/doc/constitution.1.2.wml --- doc-debian-4.0.2ubuntu1/doc/constitution.1.2.wml 2010-01-11 21:06:50.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/constitution.1.2.wml 2012-10-20 04:09:43.000000000 +0100 @@ -7,7 +7,7 @@ ratified on December 2nd, 1998. Superseded by version 1.3, ratified on September 24th, 2006. -That was superceded by the current version, 1.4 +That was superseded by the current version, 1.4 ratified on October 7th, 2007.

      @@ -935,7 +935,7 @@

      B. Use of language and typography

      The present indicative (is, for example) means that the statement -is a rule in this constitution. ay or can indicates that the +is a rule in this constitution. May or can indicates that the person or body has discretion. Should means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale diff -Nru doc-debian-4.0.2ubuntu1/doc/constitution.1.3.txt doc-debian-6.1ubuntu1/doc/constitution.1.3.txt --- doc-debian-4.0.2ubuntu1/doc/constitution.1.3.txt 2010-01-11 21:11:07.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/constitution.1.3.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,608 +0,0 @@ - Historical version of the Constitution for the Debian Project (v1.3) - - Version 1.3 ratified on September 24th, 2006. Supersedes Version 1.2 - ratified on October 29th, 2003 and Version 1.1 ratified on June 21st, - 2003, which itself supersedes Version 1.0 ratified on December 2nd, - 1998. That was superceded by the current version, 1.4 ratified on - October 7th, 2007. - 1. Introduction - - The Debian Project is an association of individuals who have made - common cause to create a free operating system. - - This document describes the organisational structure for formal - decision-making in the Project. It does not describe the goals of the - Project or how it achieves them, or contain any policies except those - directly related to the decision-making process. - 2. Decision-making bodies and individuals - - Each decision in the Project is made by one or more of the following: - 1. The Developers, by way of General Resolution or an election; - 2. The Project Leader; - 3. The Technical Committee and/or its Chairman; - 4. The individual Developer working on a particular task; - 5. Delegates appointed by the Project Leader for specific tasks; - 6. The Project Secretary. - - Most of the remainder of this document will outline the powers of these - bodies, their composition and appointment, and the procedure for their - decision-making. The powers of a person or body may be subject to - review and/or limitation by others; in this case the reviewing body or - person's entry will state this. In the list above, a person or body is - usually listed before any people or bodies whose decisions they can - overrule or who they (help) appoint - but not everyone listed earlier - can overrule everyone listed later. - - 2.1. General rules - - 1. Nothing in this constitution imposes an obligation on anyone to do - work for the Project. A person who does not want to do a task which - has been delegated or assigned to them does not need to do it. - However, they must not actively work against these rules and - decisions properly made under them. - 2. A person may hold several posts, except that the Project Leader, - Project Secretary and the Chairman of the Technical Committee must - be distinct, and that the Leader cannot appoint themselves as their - own Delegate. - 3. A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly. - - 3. Individual Developers - - 3.1. Powers - - An individual Developer may - 1. make any technical or nontechnical decision with regard to their - own work; - 2. propose or sponsor draft General Resolutions; - 3. propose themselves as a Project Leader candidate in elections; - 4. vote on General Resolutions and in Leadership elections. - - 3.2. Composition and appointment - - 1. Developers are volunteers who agree to further the aims of the - Project insofar as they participate in it, and who maintain - package(s) for the Project or do other work which the Project - Leader's Delegate(s) consider worthwhile. - 2. The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. If the Developers feel - that the Delegates are abusing their authority they can of course - override the decision by way of General Resolution - see §4.1(3), - §4.2. - - 3.3. Procedure - - Developers may make these decisions as they see fit. - 4. The Developers by way of General Resolution or election - - 4.1. Powers - - Together, the Developers may: - 1. Appoint or recall the Project Leader. - 2. Amend this constitution, provided they agree with a 3:1 majority. - 3. Make or override any decision authorised by the powers of the - Project Leader or a Delegate. - 4. Make or override any decision authorised by the powers of the - Technical Committee, provided they agree with a 2:1 majority. - 5. Issue, supersede and withdraw nontechnical policy documents and - statements. - These include documents describing the goals of the project, its - relationship with other free software entities, and nontechnical - policies such as the free software licence terms that Debian - software must meet. - They may also include position statements about issues of the day. - 1. A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes. - 2. The Foundation Documents are the works entitled "Debian Social - Contract" and "Debian Free Software Guidelines". - 3. A Foundation Document requires a 3:1 majority for its - supersession. New Foundation Documents are issued and existing - ones withdrawn by amending the list of Foundation Documents in - this constitution. - 6. Make decisions about property held in trust for purposes related to - Debian. (See §9.). - 7. In case of a disagreement between the project leader and the - incumbent secretary, appoint a new secretary. - - 4.2. Procedure - - 1. The Developers follow the Standard Resolution Procedure, below. A - resolution or amendment is introduced if proposed by any Developer - and sponsored by at least K other Developers, or if proposed by the - Project Leader or the Technical Committee. - 2. Delaying a decision by the Project Leader or their Delegate: - 1. If the Project Leader or their Delegate, or the Technical - Committee, has made a decision, then Developers can override - them by passing a resolution to do so; see §4.1(3). - 2. If such a resolution is sponsored by at least 2K Developers, - or if it is proposed by the Technical Committee, the - resolution puts the decision immediately on hold (provided - that resolution itself says so). - 3. If the original decision was to change a discussion period or - a voting period, or the resolution is to override the - Technical Committee, then only K Developers need to sponsor - the resolution to be able to put the decision immediately on - hold. - 4. If the decision is put on hold, an immediate vote is held to - determine whether the decision will stand until the full vote - on the decision is made or whether the implementation of the - original decision will be delayed until then. There is no - quorum for this immediate procedural vote. - 5. If the Project Leader (or the Delegate) withdraws the original - decision, the vote becomes moot, and is no longer conducted. - 3. Votes are taken by the Project Secretary. Votes, tallies, and - results are not revealed during the voting period; after the vote - the Project Secretary lists all the votes cast. The voting period - is 2 weeks, but may be varied by up to 1 week by the Project - Leader. - 4. The minimum discussion period is 2 weeks, but may be varied by up - to 1 week by the Project Leader. The Project Leader has a casting - vote. There is a quorum of 3Q. - 5. Proposals, sponsors, amendments, calls for votes and other formal - actions are made by announcement on a publicly-readable electronic - mailing list designated by the Project Leader's Delegate(s); any - Developer may post there. - 6. Votes are cast by email in a manner suitable to the Secretary. The - Secretary determines for each poll whether voters can change their - votes. - 7. Q is half of the square root of the number of current Developers. K - is Q or 5, whichever is the smaller. Q and K need not be integers - and are not rounded. - - 5. Project Leader - - 5.1. Powers - - The Project Leader may: - 1. Appoint Delegates or delegate decisions to the Technical Committee. - The Leader may define an area of ongoing responsibility or a - specific decision and hand it over to another Developer or to the - Technical Committee. - Once a particular decision has been delegated and made the Project - Leader may not withdraw that delegation; however, they may withdraw - an ongoing delegation of particular area of responsibility. - 2. Lend authority to other Developers. - The Project Leader may make statements of support for points of - view or for other members of the project, when asked or otherwise; - these statements have force if and only if the Leader would be - empowered to make the decision in question. - 3. Make any decision which requires urgent action. - This does not apply to decisions which have only become gradually - urgent through lack of relevant action, unless there is a fixed - deadline. - 4. Make any decision for whom noone else has responsibility. - 5. Propose draft General Resolutions and amendments. - 6. Together with the Technical Committee, appoint new members to the - Committee. (See §6.2.) - 7. Use a casting vote when Developers vote. - The Project Leader also has a normal vote in such ballots. - 8. Vary the discussion period for Developers' votes (as above). - 9. Lead discussions amongst Developers. - The Project Leader should attempt to participate in discussions - amongst the Developers in a helpful way which seeks to bring the - discussion to bear on the key issues at hand. The Project Leader - should not use the Leadership position to promote their own - personal views. - 10. In consultation with the developers, make decisions affecting - property held in trust for purposes related to Debian. (See §9.). - Such decisions are communicated to the members by the Project - Leader or their Delegate(s). Major expenditures should be proposed - and debated on the mailing list before funds are disbursed. - 11. Add or remove organizations from the list of trusted organizations - (see §9.3) that are authorized to accept and hold assets for - Debian. The evaluation and discussion leading up to such a decision - occurs on an electronic mailing list designated by the Project - Leader or their Delegate(s), on which any developer may post. There - is a minimum discussion period of two weeks before an organization - may be added to the list of trusted organizations. - - 5.2. Appointment - - 1. The Project Leader is elected by the Developers. - 2. The election begins nine weeks before the leadership post becomes - vacant, or (if it is too late already) immediately. - 3. For the following three weeks any Developer may nominate themselves - as a candidate Project Leader. - 4. For three weeks after that no more candidates may be nominated; - candidates should use this time for campaigning (to make their - identities and positions known). If there are no candidates at the - end of the nomination period then the nomination period is extended - for three further weeks, repeatedly if necessary. - 5. The next three weeks are the polling period during which Developers - may cast their votes. Votes in leadership elections are kept - secret, even after the election is finished. - 6. The options on the ballot will be those candidates who have - nominated themselves and have not yet withdrawn, plus None Of The - Above. If None Of The Above wins the election then the election - procedure is repeated, many times if necessary. - 7. The decision will be made using the method specified in section - §A.6 of the Standard Resolution Procedure. The quorum is the same - as for a General Resolution (§4.2) and the default option is "None - Of The Above". - 8. The Project Leader serves for one year from their election. - - 5.3. Procedure - - The Project Leader should attempt to make decisions which are - consistent with the consensus of the opinions of the Developers. - - Where practical the Project Leader should informally solicit the views - of the Developers. - - The Project Leader should avoid overemphasizing their own point of view - when making decisions in their capacity as Leader. - 6. Technical committee - - 6.1. Powers - - The Technical Committee may: - 1. Decide on any matter of technical policy. - This includes the contents of the technical policy manuals, - developers' reference materials, example packages and the behaviour - of non-experimental package building tools. (In each case the usual - maintainer of the relevant software or documentation makes - decisions initially, however; see 6.3(5).) - 2. Decide any technical matter where Developers' jurisdictions - overlap. - In cases where Developers need to implement compatible technical - policies or stances (for example, if they disagree about the - priorities of conflicting packages, or about ownership of a command - name, or about which package is responsible for a bug that both - maintainers agree is a bug, or about who should be the maintainer - for a package) the technical committee may decide the matter. - 3. Make a decision when asked to do so. - Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it. - 4. Overrule a Developer (requires a 3:1 majority). - The Technical Committee may ask a Developer to take a particular - technical course of action even if the Developer does not wish to; - this requires a 3:1 majority. For example, the Committee may - determine that a complaint made by the submitter of a bug is - justified and that the submitter's proposed solution should be - implemented. - 5. Offer advice. - The Technical Committee may make formal announcements about its - views on any matter. Individual members may of course make informal - statements about their views and about the likely views of the - committee. - 6. Together with the Project Leader, appoint new members to itself or - remove existing members. (See §6.2.) - 7. Appoint the Chairman of the Technical Committee. - The Chairman is elected by the Committee from its members. All - members of the committee are automatically nominated; the committee - votes starting one week before the post will become vacant (or - immediately, if it is already too late). The members may vote by - public acclamation for any fellow committee member, including - themselves; there is no default option. The vote finishes when all - the members have voted, or when the voting period has ended. The - result is determined using the method specified in section A.6 of - the Standard Resolution Procedure. - 8. The Chairman can stand in for the Leader, together with the - Secretary - As detailed in §7.1(2), the Chairman of the Technical Committee and - the Project Secretary may together stand in for the Leader if there - is no Leader. - - 6.2. Composition - - 1. The Technical Committee consists of up to 8 Developers, and should - usually have at least 4 members. - 2. When there are fewer than 8 members the Technical Committee may - recommend new member(s) to the Project Leader, who may choose - (individually) to appoint them or not. - 3. When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6. - 4. When there have been 5 members or fewer for at least one week the - Project Leader may appoint new member(s) until the number of - members reaches 6, at intervals of at least one week per - appointment. - 5. If the Technical Committee and the Project Leader agree they may - remove or replace an existing member of the Technical Committee. - - 6.3. Procedure - - 1. The Technical Committee uses the Standard Resolution Procedure. - A draft resolution or amendment may be proposed by any member of - the Technical Committee. There is no minimum discussion period; the - voting period lasts for up to one week, or until the outcome is no - longer in doubt. Members may change their votes. There is a quorum - of two. - 2. Details regarding voting - The Chairman has a casting vote. When the Technical Committee votes - whether to override a Developer who also happens to be a member of - the Committee, that member may not vote (unless they are the - Chairman, in which case they may use only their casting vote). - 3. Public discussion and decision-making. - Discussion, draft resolutions and amendments, and votes by members - of the committee, are made public on the Technical Committee public - discussion list. There is no separate secretary for the Committee. - 4. Confidentiality of appointments. - The Technical Committee may hold confidential discussions via - private email or a private mailing list or other means to discuss - appointments to the Committee. However, votes on appointments must - be public. - 5. No detailed design work. - The Technical Committee does not engage in design of new proposals - and policies. Such design work should be carried out by individuals - privately or together and discussed in ordinary technical policy - and design forums. - The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere. - Individual members of the technical committee may of course - participate on their own behalf in any aspect of design and policy - work. - 6. Technical Committee makes decisions only as last resort. - The Technical Committee does not make a technical decision until - efforts to resolve it via consensus have been tried and failed, - unless it has been asked to make a decision by the person or body - who would normally be responsible for it. - - 7. The Project Secretary - - 7.1. Powers - - The Secretary: - 1. Takes votes amongst the Developers, and determines the number and - identity of Developers, whenever this is required by the - constitution. - 2. Can stand in for the Leader, together with the Chairman of the - Technical Committee. - If there is no Project Leader then the Chairman of the Technical - Committee and the Project Secretary may by joint agreement make - decisions if they consider it imperative to do so. - 3. Adjudicates any disputes about interpretation of the constitution. - 4. May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time. - - 7.2. Appointment - - The Project Secretary is appointed by the Project Leader and the - current Project Secretary. - - If the Project Leader and the current Project Secretary cannot agree on - a new appointment, they must ask the Developers by way of General - Resolution to appoint a Secretary. - - If there is no Project Secretary or the current Secretary is - unavailable and has not delegated authority for a decision then the - decision may be made or delegated by the Chairman of the Technical - Committee, as Acting Secretary. - - The Project Secretary's term of office is 1 year, at which point they - or another Secretary must be (re)appointed. - - 7.3. Procedure - - The Project Secretary should make decisions which are fair and - reasonable, and preferably consistent with the consensus of the - Developers. - - When acting together to stand in for an absent Project Leader the - Chairman of the Technical Committee and the Project Secretary should - make decisions only when absolutely necessary and only when consistent - with the consensus of the Developers. - 8. The Project Leader's Delegates - - 8.1. Powers - - The Project Leader's Delegates: - 1. have powers delegated to them by the Project Leader; - 2. may make certain decisions which the Leader may not make directly, - including approving or expelling Developers or designating people - as Developers who do not maintain packages. This is to avoid - concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader. - - 8.2. Appointment - - The Delegates are appointed by the Project Leader and may be replaced - by the Leader at the Leader's discretion. The Project Leader may not - make the position as a Delegate conditional on particular decisions by - the Delegate, nor may they override a decision made by a Delegate once - made. - - 8.3. Procedure - - Delegates may make decisions as they see fit, but should attempt to - implement good technical decisions and/or follow consensus opinion. - 9. Assets held in trust for Debian - - In most jurisdictions around the world, the Debian project is not in a - position to directly hold funds or other property. Therefore, property - has to be owned by any of a number of organisations as detailed in - §9.2. - - Traditionally, SPI was the sole organisation authorized to hold - property and monies for the Debian Project. SPI was created in the U.S. - to hold money in trust there. - - SPI and Debian are separate organisations who share some goals. Debian - is grateful for the legal support framework offered by SPI. - - 9.1. Relationship with Associated Organizations - - 1. Debian Developers do not become agents or employees of - organisations holding assets in trust for Debian, or of each other, - or of persons in authority in the Debian Project, solely by the - virtue of being Debian Developers. A person acting as a Developer - does so as an individual, on their own behalf. Such organisations - may, of their own accord, establish relationships with individuals - who are also Debian developers. - - 9.2. Authority - - 1. An organisation holding assets for Debian has no authority - regarding Debian's technical or nontechnical decisions, except that - no decision by Debian with respect to any property held by the - organisation shall require it to act outside its legal authority. - 2. Debian claims no authority over an organisation that holds assets - for Debian other than that over the use of property held in trust - for Debian. - - 9.3. Trusted organisations - - Any donations for the Debian Project must be made to any one of a set - of organisations designated by the Project leader (or a delegate) to be - authorized to handle assets to be used for the Debian Project. - - Organisations holding assets in trust for Debian should undertake - reasonable obligations for the handling of such assets. - - Debian maintains a public List of Trusted Organisations that accept - donations and hold assets in trust for Debian (including both tangible - property and intellectual property) that includes the commitments those - organisations have made as to how those assets will be handled. - A. Standard Resolution Procedure - - These rules apply to communal decision-making by committees and - plebiscites, where stated above. - - A.1. Proposal - - The formal procedure begins when a draft resolution is proposed and - sponsored, as required. - - A.1. Discussion and Amendment - - 1. Following the proposal, the resolution may be discussed. Amendments - may be made formal by being proposed and sponsored according to the - requirements for a new resolution, or directly by the proposer of - the original resolution. - 2. A formal amendment may be accepted by the resolution's proposer, in - which case the formal resolution draft is immediately changed to - match. - 3. If a formal amendment is not accepted, or one of the sponsors of - the resolution does not agree with the acceptance by the proposer - of a formal amendment, the amendment remains as an amendment and - will be voted on. - 4. If an amendment accepted by the original proposer is not to the - liking of others, they may propose another amendment to reverse the - earlier change (again, they must meet the requirements for proposer - and sponsor(s).) - 5. The proposer of a resolution may suggest changes to the wordings of - amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals. - 6. The proposer of a resolution may make changes to correct minor - errors (for example, typographical errors or inconsistencies) or - changes which do not alter the meaning, providing noone objects - within 24 hours. In this case the minimum discussion period is not - restarted. - - A.2. Calling for a vote - - 1. The proposer or a sponsor of a motion or an amendment may call for - a vote, providing that the minimum discussion period (if any) has - elapsed. - 2. The proposer or any sponsor of a resolution may call for a vote on - that resolution and all related amendments. - 3. The person who calls for a vote states what they believe the - wordings of the resolution and any relevant amendments are, and - consequently what form the ballot should take. However, the final - decision on the form of ballot(s) is the Secretary's - see 7.1(1), - 7.1(3) and A.3(4). - 4. The minimum discussion period is counted from the time the last - formal amendment was accepted, or since the whole resolution was - proposed if no amendments have been proposed and accepted. - - A.3. Voting procedure - - 1. Each resolution and its related amendments is voted on in a single - ballot that includes an option for the original resolution, each - amendment, and the default option (where applicable). - 2. The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - 3. The votes are counted according to the rules in A.6. The default - option is "Further Discussion", unless specified otherwise. - 4. In cases of doubt the Project Secretary shall decide on matters of - procedure. - - A.4. Withdrawing resolutions or unaccepted amendments - - The proposer of a resolution or unaccepted amendment may withdraw it. - In this case new proposers may come forward keep it alive, in which - case the first person to do so becomes the new proposer and any others - become sponsors if they aren't sponsors already. - - A sponsor of a resolution or amendment (unless it has been accepted) - may withdraw. - - If the withdrawal of the proposer and/or sponsors means that a - resolution has no proposer or not enough sponsors it will not be voted - on unless this is rectified before the resolution expires. - - A.5. Expiry - - If a proposed resolution has not been discussed, amended, voted on or - otherwise dealt with for 4 weeks the secretary may issue a statement - that the issue is being withdrawn. If none of the sponsors of any of - the proposals object within a week, the issue is withdrawn. - - The secretary may also include suggestions on how to proceed, if - appropriate. - - A.6. Vote Counting - - 1. Each voter's ballot ranks the options being voted on. Not all - options need be ranked. Ranked options are considered preferred to - all unranked options. Voters may rank options equally. Unranked - options are considered to be ranked equally with one another. - Details of how ballots may be filled out will be included in the - Call For Votes. - 2. If the ballot has a quorum requirement R any options other than the - default option which do not receive at least R votes ranking that - option above the default option are dropped from consideration. - 3. Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - 1. Given two options A and B, V(A,B) is the number of voters who - prefer option A over option B. - 2. An option A defeats the default option D by a majority ratio - N, if V(A,D) is strictly greater than N * V(D,A). - 3. If a supermajority of S:1 is required for A, its majority - ratio is S; otherwise, its majority ratio is 1. - 4. From the list of undropped options, we generate a list of pairwise - defeats. - 1. An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - 5. From the list of [undropped] pairwise defeats, we generate a set of - transitive defeats. - 1. An option A transitively defeats an option C if A defeats C or - if there is some other option B where A defeats B AND B - transitively defeats C. - 6. We construct the Schwartz set from the set of transitive defeats. - 1. An option A is in the Schwartz set if for all options B, - either A transitively defeats B, or B does not transitively - defeat A. - 7. If there are defeats between options in the Schwartz set, we drop - the weakest such defeats from the list of pairwise defeats, and - return to step 5. - 1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less - than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is - equal to V(B,Y) and V(X,A) is greater than V(Y,B). - 2. A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - 8. If there are no defeats within the Schwartz set, then the winner is - chosen from the options in the Schwartz set. If there is only one - such option, it is the winner. If there are multiple options, the - elector with the casting vote chooses which of those options wins. - - Note: Options which the voters rank above the default option are - options they find acceptable. Options ranked below the default options - are options they find unacceptable. - - When the Standard Resolution Procedure is to be used, the text which - refers to it must specify what is sufficient to have a draft resolution - proposed and/or sponsored, what the minimum discussion period is, and - what the voting period is. It must also specify any supermajority - and/or the quorum (and default option) to be used. - B. Use of language and typography - - The present indicative ("is", for example) means that the statement is - a rule in this constitution. "May" or "can" indicates that the person - or body has discretion. "Should" means that it would be considered a - good thing if the sentence were obeyed, but it is not binding. Text - marked as a citation, such as this, is rationale and does not form part - of the constitution. It may be used only to aid interpretation in cases - of doubt. diff -Nru doc-debian-4.0.2ubuntu1/doc/constitution.1.3.wml doc-debian-6.1ubuntu1/doc/constitution.1.3.wml --- doc-debian-4.0.2ubuntu1/doc/constitution.1.3.wml 2010-01-11 21:11:06.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/constitution.1.3.wml 2012-10-20 04:09:43.000000000 +0100 @@ -7,13 +7,13 @@ Version 1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 ratified on December 2nd, 1998. -That was superceded by the current version, 1.4 +That was superseded by the current version, 1.4 ratified on October 7th, 2007.

      -1. Introduction +1. Introduction

      The Debian Project is an association of individuals who have made common cause to create a free operating system.

      @@ -23,7 +23,7 @@ Project or how it achieves them, or contain any policies except those directly related to the decision-making process.

      -2. Decision-making bodies and individuals +2. Decision-making bodies and individuals

      Each decision in the Project is made by one or more of the following:

      @@ -76,7 +76,7 @@ -3. Individual Developers +3. Individual Developers

      3.1. Powers

      @@ -117,7 +117,7 @@

      Developers may make these decisions as they see fit.

      -4. The Developers by way of General Resolution or election +4. The Developers by way of General Resolution or election

      4.1. Powers

      @@ -255,7 +255,7 @@ -5. Project Leader +5. Project Leader

      5.1. Powers

      @@ -393,7 +393,7 @@

      The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader.

      -6. Technical committee +6. Technical committee

      6.1. Powers

      @@ -583,7 +583,7 @@ -7. The Project Secretary +7. The Project Secretary

      7.1. Powers

      @@ -645,7 +645,7 @@ make decisions only when absolutely necessary and only when consistent with the consensus of the Developers.

      -8. The Project Leader's Delegates +8. The Project Leader's Delegates

      8.1. Powers

      @@ -674,7 +674,7 @@

      Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.

      -9. Assets held in trust for Debian +9. Assets held in trust for Debian

      In most jurisdictions around the world, the Debian project is not in a position to directly hold funds or other property. Therefore, @@ -738,7 +738,7 @@ that includes the commitments those organisations have made as to how those assets will be handled.

      -A. Standard Resolution Procedure +A. Standard Resolution Procedure

      These rules apply to communal decision-making by committees and plebiscites, where stated above.

      @@ -957,7 +957,7 @@ supermajority and/or the quorum (and default option) to be used.

      -B. Use of language and typography +B. Use of language and typography

      The present indicative (is, for example) means that the statement is a rule in this constitution. May or can indicates that the diff -Nru doc-debian-4.0.2ubuntu1/doc/constitution.txt doc-debian-6.1ubuntu1/doc/constitution.txt --- doc-debian-4.0.2ubuntu1/doc/constitution.txt 2010-01-11 21:14:08.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/constitution.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,615 +0,0 @@ - Constitution for the Debian Project (v1.4) - - Version 1.4 ratified on October 7th, 2007. Supersedes Version 1.3 - ratified on September 24th, 2006, Version 1.2 ratified on October 29th, - 2003 and Version 1.1 ratified on June 21st, 2003, which itself - supersedes Version 1.0 ratified on December 2nd, 1998. - -1. Introduction - - The Debian Project is an association of individuals who have made - common cause to create a free operating system. - - This document describes the organisational structure for formal - decision-making in the Project. It does not describe the goals of the - Project or how it achieves them, or contain any policies except those - directly related to the decision-making process. - -2. Decision-making bodies and individuals - - Each decision in the Project is made by one or more of the following: - 1. The Developers, by way of General Resolution or an election; - 2. The Project Leader; - 3. The Technical Committee and/or its Chairman; - 4. The individual Developer working on a particular task; - 5. Delegates appointed by the Project Leader for specific tasks; - 6. The Project Secretary. - - Most of the remainder of this document will outline the powers of these - bodies, their composition and appointment, and the procedure for their - decision-making. The powers of a person or body may be subject to - review and/or limitation by others; in this case the reviewing body or - person's entry will state this. In the list above, a person or body is - usually listed before any people or bodies whose decisions they can - overrule or who they (help) appoint - but not everyone listed earlier - can overrule everyone listed later. - - 2.1. General rules - - 1. Nothing in this constitution imposes an obligation on anyone to do - work for the Project. A person who does not want to do a task which - has been delegated or assigned to them does not need to do it. - However, they must not actively work against these rules and - decisions properly made under them. - 2. A person may hold several posts, except that the Project Leader, - Project Secretary and the Chairman of the Technical Committee must - be distinct, and that the Leader cannot appoint themselves as their - own Delegate. - 3. A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly. - -3. Individual Developers - - 3.1. Powers - - An individual Developer may - 1. make any technical or nontechnical decision with regard to their - own work; - 2. propose or sponsor draft General Resolutions; - 3. propose themselves as a Project Leader candidate in elections; - 4. vote on General Resolutions and in Leadership elections. - - 3.2. Composition and appointment - - 1. Developers are volunteers who agree to further the aims of the - Project insofar as they participate in it, and who maintain - package(s) for the Project or do other work which the Project - Leader's Delegate(s) consider worthwhile. - 2. The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. If the Developers feel - that the Delegates are abusing their authority they can of course - override the decision by way of General Resolution - see §4.1(3), - §4.2. - - 3.3. Procedure - - Developers may make these decisions as they see fit. - -4. The Developers by way of General Resolution or election - - 4.1. Powers - - Together, the Developers may: - 1. Appoint or recall the Project Leader. - 2. Amend this constitution, provided they agree with a 3:1 majority. - 3. Make or override any decision authorised by the powers of the - Project Leader or a Delegate. - 4. Make or override any decision authorised by the powers of the - Technical Committee, provided they agree with a 2:1 majority. - 5. Issue, supersede and withdraw nontechnical policy documents and - statements. - These include documents describing the goals of the project, its - relationship with other free software entities, and nontechnical - policies such as the free software licence terms that Debian - software must meet. - They may also include position statements about issues of the day. - 1. A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes. - 2. The Foundation Documents are the works entitled "Debian Social - Contract" and "Debian Free Software Guidelines". - 3. A Foundation Document requires a 3:1 majority for its - supersession. New Foundation Documents are issued and existing - ones withdrawn by amending the list of Foundation Documents in - this constitution. - 6. Make decisions about property held in trust for purposes related to - Debian. (See §9.). - 7. In case of a disagreement between the project leader and the - incumbent secretary, appoint a new secretary. - - 4.2. Procedure - - 1. The Developers follow the Standard Resolution Procedure, below. A - resolution or amendment is introduced if proposed by any Developer - and sponsored by at least K other Developers, or if proposed by the - Project Leader or the Technical Committee. - 2. Delaying a decision by the Project Leader or their Delegate: - 1. If the Project Leader or their Delegate, or the Technical - Committee, has made a decision, then Developers can override - them by passing a resolution to do so; see §4.1(3). - 2. If such a resolution is sponsored by at least 2K Developers, - or if it is proposed by the Technical Committee, the - resolution puts the decision immediately on hold (provided - that resolution itself says so). - 3. If the original decision was to change a discussion period or - a voting period, or the resolution is to override the - Technical Committee, then only K Developers need to sponsor - the resolution to be able to put the decision immediately on - hold. - 4. If the decision is put on hold, an immediate vote is held to - determine whether the decision will stand until the full vote - on the decision is made or whether the implementation of the - original decision will be delayed until then. There is no - quorum for this immediate procedural vote. - 5. If the Project Leader (or the Delegate) withdraws the original - decision, the vote becomes moot, and is no longer conducted. - 3. Votes are taken by the Project Secretary. Votes, tallies, and - results are not revealed during the voting period; after the vote - the Project Secretary lists all the votes cast. The voting period - is 2 weeks, but may be varied by up to 1 week by the Project - Leader. - 4. The minimum discussion period is 2 weeks, but may be varied by up - to 1 week by the Project Leader. The Project Leader has a casting - vote. There is a quorum of 3Q. - 5. Proposals, sponsors, amendments, calls for votes and other formal - actions are made by announcement on a publicly-readable electronic - mailing list designated by the Project Leader's Delegate(s); any - Developer may post there. - 6. Votes are cast by email in a manner suitable to the Secretary. The - Secretary determines for each poll whether voters can change their - votes. - 7. Q is half of the square root of the number of current Developers. K - is Q or 5, whichever is the smaller. Q and K need not be integers - and are not rounded. - -5. Project Leader - - 5.1. Powers - - The Project Leader may: - 1. Appoint Delegates or delegate decisions to the Technical Committee. - The Leader may define an area of ongoing responsibility or a - specific decision and hand it over to another Developer or to the - Technical Committee. - Once a particular decision has been delegated and made the Project - Leader may not withdraw that delegation; however, they may withdraw - an ongoing delegation of particular area of responsibility. - 2. Lend authority to other Developers. - The Project Leader may make statements of support for points of - view or for other members of the project, when asked or otherwise; - these statements have force if and only if the Leader would be - empowered to make the decision in question. - 3. Make any decision which requires urgent action. - This does not apply to decisions which have only become gradually - urgent through lack of relevant action, unless there is a fixed - deadline. - 4. Make any decision for whom noone else has responsibility. - 5. Propose draft General Resolutions and amendments. - 6. Together with the Technical Committee, appoint new members to the - Committee. (See §6.2.) - 7. Use a casting vote when Developers vote. - The Project Leader also has a normal vote in such ballots. - 8. Vary the discussion period for Developers' votes (as above). - 9. Lead discussions amongst Developers. - The Project Leader should attempt to participate in discussions - amongst the Developers in a helpful way which seeks to bring the - discussion to bear on the key issues at hand. The Project Leader - should not use the Leadership position to promote their own - personal views. - 10. In consultation with the developers, make decisions affecting - property held in trust for purposes related to Debian. (See §9.). - Such decisions are communicated to the members by the Project - Leader or their Delegate(s). Major expenditures should be proposed - and debated on the mailing list before funds are disbursed. - 11. Add or remove organizations from the list of trusted organizations - (see §9.3) that are authorized to accept and hold assets for - Debian. The evaluation and discussion leading up to such a decision - occurs on an electronic mailing list designated by the Project - Leader or their Delegate(s), on which any developer may post. There - is a minimum discussion period of two weeks before an organization - may be added to the list of trusted organizations. - - 5.2. Appointment - - 1. The Project Leader is elected by the Developers. - 2. The election begins six weeks before the leadership post becomes - vacant, or (if it is too late already) immediately. - 3. For the first week any Developer may nominate themselves as a - candidate Project Leader, and summarize their plans for their term. - 4. For three weeks after that no more candidates may be nominated; - candidates should use this time for campaigning and discussion. If - there are no candidates at the end of the nomination period then - the nomination period is extended for an additional week, - repeatedly if necessary. - 5. The next two weeks are the polling period during which Developers - may cast their votes. Votes in leadership elections are kept - secret, even after the election is finished. - 6. The options on the ballot will be those candidates who have - nominated themselves and have not yet withdrawn, plus None Of The - Above. If None Of The Above wins the election then the election - procedure is repeated, many times if necessary. - 7. The decision will be made using the method specified in section - §A.6 of the Standard Resolution Procedure. The quorum is the same - as for a General Resolution (§4.2) and the default option is "None - Of The Above". - 8. The Project Leader serves for one year from their election. - - 5.3. Procedure - - The Project Leader should attempt to make decisions which are - consistent with the consensus of the opinions of the Developers. - - Where practical the Project Leader should informally solicit the views - of the Developers. - - The Project Leader should avoid overemphasizing their own point of view - when making decisions in their capacity as Leader. - -6. Technical committee - - 6.1. Powers - - The Technical Committee may: - 1. Decide on any matter of technical policy. - This includes the contents of the technical policy manuals, - developers' reference materials, example packages and the behaviour - of non-experimental package building tools. (In each case the usual - maintainer of the relevant software or documentation makes - decisions initially, however; see 6.3(5).) - 2. Decide any technical matter where Developers' jurisdictions - overlap. - In cases where Developers need to implement compatible technical - policies or stances (for example, if they disagree about the - priorities of conflicting packages, or about ownership of a command - name, or about which package is responsible for a bug that both - maintainers agree is a bug, or about who should be the maintainer - for a package) the technical committee may decide the matter. - 3. Make a decision when asked to do so. - Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it. - 4. Overrule a Developer (requires a 3:1 majority). - The Technical Committee may ask a Developer to take a particular - technical course of action even if the Developer does not wish to; - this requires a 3:1 majority. For example, the Committee may - determine that a complaint made by the submitter of a bug is - justified and that the submitter's proposed solution should be - implemented. - 5. Offer advice. - The Technical Committee may make formal announcements about its - views on any matter. Individual members may of course make informal - statements about their views and about the likely views of the - committee. - 6. Together with the Project Leader, appoint new members to itself or - remove existing members. (See §6.2.) - 7. Appoint the Chairman of the Technical Committee. - The Chairman is elected by the Committee from its members. All - members of the committee are automatically nominated; the committee - votes starting one week before the post will become vacant (or - immediately, if it is already too late). The members may vote by - public acclamation for any fellow committee member, including - themselves; there is no default option. The vote finishes when all - the members have voted, or when the voting period has ended. The - result is determined using the method specified in section A.6 of - the Standard Resolution Procedure. - 8. The Chairman can stand in for the Leader, together with the - Secretary - As detailed in §7.1(2), the Chairman of the Technical Committee and - the Project Secretary may together stand in for the Leader if there - is no Leader. - - 6.2. Composition - - 1. The Technical Committee consists of up to 8 Developers, and should - usually have at least 4 members. - 2. When there are fewer than 8 members the Technical Committee may - recommend new member(s) to the Project Leader, who may choose - (individually) to appoint them or not. - 3. When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6. - 4. When there have been 5 members or fewer for at least one week the - Project Leader may appoint new member(s) until the number of - members reaches 6, at intervals of at least one week per - appointment. - 5. If the Technical Committee and the Project Leader agree they may - remove or replace an existing member of the Technical Committee. - - 6.3. Procedure - - 1. The Technical Committee uses the Standard Resolution Procedure. - A draft resolution or amendment may be proposed by any member of - the Technical Committee. There is no minimum discussion period; the - voting period lasts for up to one week, or until the outcome is no - longer in doubt. Members may change their votes. There is a quorum - of two. - 2. Details regarding voting - The Chairman has a casting vote. When the Technical Committee votes - whether to override a Developer who also happens to be a member of - the Committee, that member may not vote (unless they are the - Chairman, in which case they may use only their casting vote). - 3. Public discussion and decision-making. - Discussion, draft resolutions and amendments, and votes by members - of the committee, are made public on the Technical Committee public - discussion list. There is no separate secretary for the Committee. - 4. Confidentiality of appointments. - The Technical Committee may hold confidential discussions via - private email or a private mailing list or other means to discuss - appointments to the Committee. However, votes on appointments must - be public. - 5. No detailed design work. - The Technical Committee does not engage in design of new proposals - and policies. Such design work should be carried out by individuals - privately or together and discussed in ordinary technical policy - and design forums. - The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere. - Individual members of the technical committee may of course - participate on their own behalf in any aspect of design and policy - work. - 6. Technical Committee makes decisions only as last resort. - The Technical Committee does not make a technical decision until - efforts to resolve it via consensus have been tried and failed, - unless it has been asked to make a decision by the person or body - who would normally be responsible for it. - -7. The Project Secretary - - 7.1. Powers - - The Secretary: - 1. Takes votes amongst the Developers, and determines the number and - identity of Developers, whenever this is required by the - constitution. - 2. Can stand in for the Leader, together with the Chairman of the - Technical Committee. - If there is no Project Leader then the Chairman of the Technical - Committee and the Project Secretary may by joint agreement make - decisions if they consider it imperative to do so. - 3. Adjudicates any disputes about interpretation of the constitution. - 4. May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time. - - 7.2. Appointment - - The Project Secretary is appointed by the Project Leader and the - current Project Secretary. - - If the Project Leader and the current Project Secretary cannot agree on - a new appointment, they must ask the Developers by way of General - Resolution to appoint a Secretary. - - If there is no Project Secretary or the current Secretary is - unavailable and has not delegated authority for a decision then the - decision may be made or delegated by the Chairman of the Technical - Committee, as Acting Secretary. - - The Project Secretary's term of office is 1 year, at which point they - or another Secretary must be (re)appointed. - - 7.3. Procedure - - The Project Secretary should make decisions which are fair and - reasonable, and preferably consistent with the consensus of the - Developers. - - When acting together to stand in for an absent Project Leader the - Chairman of the Technical Committee and the Project Secretary should - make decisions only when absolutely necessary and only when consistent - with the consensus of the Developers. - -8. The Project Leader's Delegates - - 8.1. Powers - - The Project Leader's Delegates: - 1. have powers delegated to them by the Project Leader; - 2. may make certain decisions which the Leader may not make directly, - including approving or expelling Developers or designating people - as Developers who do not maintain packages. This is to avoid - concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader. - - 8.2. Appointment - - The Delegates are appointed by the Project Leader and may be replaced - by the Leader at the Leader's discretion. The Project Leader may not - make the position as a Delegate conditional on particular decisions by - the Delegate, nor may they override a decision made by a Delegate once - made. - - 8.3. Procedure - - Delegates may make decisions as they see fit, but should attempt to - implement good technical decisions and/or follow consensus opinion. - -9. Assets held in trust for Debian - - In most jurisdictions around the world, the Debian project is not in a - position to directly hold funds or other property. Therefore, property - has to be owned by any of a number of organisations as detailed in - §9.2. - - Traditionally, SPI was the sole organisation authorized to hold - property and monies for the Debian Project. SPI was created in the U.S. - to hold money in trust there. - - SPI and Debian are separate organisations who share some goals. Debian - is grateful for the legal support framework offered by SPI. - - 9.1. Relationship with Associated Organizations - - 1. Debian Developers do not become agents or employees of - organisations holding assets in trust for Debian, or of each other, - or of persons in authority in the Debian Project, solely by the - virtue of being Debian Developers. A person acting as a Developer - does so as an individual, on their own behalf. Such organisations - may, of their own accord, establish relationships with individuals - who are also Debian developers. - - 9.2. Authority - - 1. An organisation holding assets for Debian has no authority - regarding Debian's technical or nontechnical decisions, except that - no decision by Debian with respect to any property held by the - organisation shall require it to act outside its legal authority. - 2. Debian claims no authority over an organisation that holds assets - for Debian other than that over the use of property held in trust - for Debian. - - 9.3. Trusted organisations - - Any donations for the Debian Project must be made to any one of a set - of organisations designated by the Project leader (or a delegate) to be - authorized to handle assets to be used for the Debian Project. - - Organisations holding assets in trust for Debian should undertake - reasonable obligations for the handling of such assets. - - Debian maintains a public List of Trusted Organisations that accept - donations and hold assets in trust for Debian (including both tangible - property and intellectual property) that includes the commitments those - organisations have made as to how those assets will be handled. - -A. Standard Resolution Procedure - - These rules apply to communal decision-making by committees and - plebiscites, where stated above. - - A.1. Proposal - - The formal procedure begins when a draft resolution is proposed and - sponsored, as required. - - A.1. Discussion and Amendment - - 1. Following the proposal, the resolution may be discussed. Amendments - may be made formal by being proposed and sponsored according to the - requirements for a new resolution, or directly by the proposer of - the original resolution. - 2. A formal amendment may be accepted by the resolution's proposer, in - which case the formal resolution draft is immediately changed to - match. - 3. If a formal amendment is not accepted, or one of the sponsors of - the resolution does not agree with the acceptance by the proposer - of a formal amendment, the amendment remains as an amendment and - will be voted on. - 4. If an amendment accepted by the original proposer is not to the - liking of others, they may propose another amendment to reverse the - earlier change (again, they must meet the requirements for proposer - and sponsor(s).) - 5. The proposer of a resolution may suggest changes to the wordings of - amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals. - 6. The proposer of a resolution may make changes to correct minor - errors (for example, typographical errors or inconsistencies) or - changes which do not alter the meaning, providing noone objects - within 24 hours. In this case the minimum discussion period is not - restarted. - - A.2. Calling for a vote - - 1. The proposer or a sponsor of a motion or an amendment may call for - a vote, providing that the minimum discussion period (if any) has - elapsed. - 2. The proposer or any sponsor of a resolution may call for a vote on - that resolution and all related amendments. - 3. The person who calls for a vote states what they believe the - wordings of the resolution and any relevant amendments are, and - consequently what form the ballot should take. However, the final - decision on the form of ballot(s) is the Secretary's - see 7.1(1), - 7.1(3) and A.3(4). - 4. The minimum discussion period is counted from the time the last - formal amendment was accepted, or since the whole resolution was - proposed if no amendments have been proposed and accepted. - - A.3. Voting procedure - - 1. Each resolution and its related amendments is voted on in a single - ballot that includes an option for the original resolution, each - amendment, and the default option (where applicable). - 2. The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - 3. The votes are counted according to the rules in A.6. The default - option is "Further Discussion", unless specified otherwise. - 4. In cases of doubt the Project Secretary shall decide on matters of - procedure. - - A.4. Withdrawing resolutions or unaccepted amendments - - The proposer of a resolution or unaccepted amendment may withdraw it. - In this case new proposers may come forward keep it alive, in which - case the first person to do so becomes the new proposer and any others - become sponsors if they aren't sponsors already. - - A sponsor of a resolution or amendment (unless it has been accepted) - may withdraw. - - If the withdrawal of the proposer and/or sponsors means that a - resolution has no proposer or not enough sponsors it will not be voted - on unless this is rectified before the resolution expires. - - A.5. Expiry - - If a proposed resolution has not been discussed, amended, voted on or - otherwise dealt with for 4 weeks the secretary may issue a statement - that the issue is being withdrawn. If none of the sponsors of any of - the proposals object within a week, the issue is withdrawn. - - The secretary may also include suggestions on how to proceed, if - appropriate. - - A.6. Vote Counting - - 1. Each voter's ballot ranks the options being voted on. Not all - options need be ranked. Ranked options are considered preferred to - all unranked options. Voters may rank options equally. Unranked - options are considered to be ranked equally with one another. - Details of how ballots may be filled out will be included in the - Call For Votes. - 2. If the ballot has a quorum requirement R any options other than the - default option which do not receive at least R votes ranking that - option above the default option are dropped from consideration. - 3. Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - 1. Given two options A and B, V(A,B) is the number of voters who - prefer option A over option B. - 2. An option A defeats the default option D by a majority ratio - N, if V(A,D) is strictly greater than N * V(D,A). - 3. If a supermajority of S:1 is required for A, its majority - ratio is S; otherwise, its majority ratio is 1. - 4. From the list of undropped options, we generate a list of pairwise - defeats. - 1. An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - 5. From the list of [undropped] pairwise defeats, we generate a set of - transitive defeats. - 1. An option A transitively defeats an option C if A defeats C or - if there is some other option B where A defeats B AND B - transitively defeats C. - 6. We construct the Schwartz set from the set of transitive defeats. - 1. An option A is in the Schwartz set if for all options B, - either A transitively defeats B, or B does not transitively - defeat A. - 7. If there are defeats between options in the Schwartz set, we drop - the weakest such defeats from the list of pairwise defeats, and - return to step 5. - 1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less - than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is - equal to V(B,Y) and V(X,A) is greater than V(Y,B). - 2. A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - 8. If there are no defeats within the Schwartz set, then the winner is - chosen from the options in the Schwartz set. If there is only one - such option, it is the winner. If there are multiple options, the - elector with the casting vote chooses which of those options wins. - - Note: Options which the voters rank above the default option are - options they find acceptable. Options ranked below the default options - are options they find unacceptable. - - When the Standard Resolution Procedure is to be used, the text which - refers to it must specify what is sufficient to have a draft resolution - proposed and/or sponsored, what the minimum discussion period is, and - what the voting period is. It must also specify any supermajority - and/or the quorum (and default option) to be used. - -B. Use of language and typography - - The present indicative ("is", for example) means that the statement is - a rule in this constitution. "May" or "can" indicates that the person - or body has discretion. "Should" means that it would be considered a - good thing if the sentence were obeyed, but it is not binding. Text - marked as a citation, such as this, is rationale and does not form part - of the constitution. It may be used only to aid interpretation in cases - of doubt. diff -Nru doc-debian-4.0.2ubuntu1/doc/constitution.wml doc-debian-6.1ubuntu1/doc/constitution.wml --- doc-debian-4.0.2ubuntu1/doc/constitution.wml 2010-01-11 21:14:08.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/constitution.wml 2012-10-20 04:09:43.000000000 +0100 @@ -13,7 +13,7 @@ -

      1. Introduction

      +

      1. Introduction

      The Debian Project is an association of individuals who have made common cause to create a free operating system.

      @@ -23,7 +23,7 @@ Project or how it achieves them, or contain any policies except those directly related to the decision-making process.

      -

      2. Decision-making bodies and individuals

      +

      2. Decision-making bodies and individuals

      Each decision in the Project is made by one or more of the following:

      @@ -76,7 +76,7 @@ -

      3. Individual Developers

      +

      3. Individual Developers

      3.1. Powers

      @@ -117,7 +117,7 @@

      Developers may make these decisions as they see fit.

      -

      4. The Developers by way of General Resolution or election

      +

      4. The Developers by way of General Resolution or election

      4.1. Powers

      @@ -255,7 +255,7 @@ -

      5. Project Leader

      +

      5. Project Leader

      5.1. Powers

      @@ -393,7 +393,7 @@

      The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader.

      -

      6. Technical committee

      +

      6. Technical committee

      6.1. Powers

      @@ -583,7 +583,7 @@ -

      7. The Project Secretary

      +

      7. The Project Secretary

      7.1. Powers

      @@ -645,7 +645,7 @@ make decisions only when absolutely necessary and only when consistent with the consensus of the Developers.

      -

      8. The Project Leader's Delegates

      +

      8. The Project Leader's Delegates

      8.1. Powers

      @@ -674,7 +674,7 @@

      Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion.

      -

      9. Assets held in trust for Debian

      +

      9. Assets held in trust for Debian

      In most jurisdictions around the world, the Debian project is not in a position to directly hold funds or other property. Therefore, @@ -738,7 +738,7 @@ that includes the commitments those organisations have made as to how those assets will be handled.

      -

      A. Standard Resolution Procedure

      +

      A. Standard Resolution Procedure

      These rules apply to communal decision-making by committees and plebiscites, where stated above.

      @@ -957,7 +957,7 @@ supermajority and/or the quorum (and default option) to be used.

      -

      B. Use of language and typography

      +

      B. Use of language and typography

      The present indicative (is, for example) means that the statement is a rule in this constitution. May or can indicates that the diff -Nru doc-debian-4.0.2ubuntu1/doc/Makefile doc-debian-6.1ubuntu1/doc/Makefile --- doc-debian-4.0.2ubuntu1/doc/Makefile 2010-01-11 21:14:21.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/Makefile 2012-12-05 18:34:42.000000000 +0000 @@ -1,22 +1,38 @@ - +# Makefile to build the txt and html files for the +# doc-debian package LANGUAGE = english # Adjust this (or create a symlink) to the location of your webml copy (if you have one) +# If this directory does not exist the 'update' call will not be able to run, read +# the README-build file to know how to set it up WEBWML = ~/debian/www/webwml/$(LANGUAGE) -FILES= \ -bug-log-access.txt bug-maint-mailcontrol.txt constitution.1.0.txt \ -bug-log-mailserver.txt bug-reporting.txt mailing-lists.txt \ -bug-mailserver-refcard.txt constitution.txt social-contract.txt \ -bug-maint-info.txt constitution.1.1.txt social-contract.1.0.txt \ -constitution.1.2.txt social-contract.txt constitution.1.3.txt +WMLFILES= \ +bug-log-access.wml bug-maint-mailcontrol.wml constitution.1.0.wml \ +bug-log-mailserver.wml bug-reporting.wml \ +bug-mailserver-refcard.wml constitution.wml social-contract.wml \ +bug-maint-info.wml constitution.1.1.wml social-contract.1.0.wml \ +constitution.1.2.wml social-contract.wml constitution.1.3.wml + +# These are the automatic files we can generate: +TXTFILES = $(subst .wml,.txt,$(WMLFILES)) +HTMLFILES = $(subst .wml,.html,$(WMLFILES)) +GENERATED_FILES = $(TXTFILES) $(HTMLFILES) +# Mailing lists does not have an associated wml file, so we add it separately +# to keep GENERATED_FILES to be just those that are built with the Makefile + +all: $(TXTFILES) -all: $(FILES) +wml: $(WMLFILES) + +update: + @$(MAKE) wml clean: - -rm -f $(FILES) *.html + -rm -f $(GENERATED_FILES) + realclean: clean - -rm -f *.wml + -rm -f $(WMLFILES) %.html: %.wml wml -q $< >$@ @@ -62,9 +78,12 @@ mailing-lists.txt: $(WEBWML)/MailingLists/mailing-lists.txt cp $< $@ -## the Makfile in $(WEBWML)/MailingLists needs internet access! +## the Makefile in $(WEBWML)/MailingLists needs internet access! $(WEBWML)/MailingLists/mailing-lists.txt: cd $(WEBWML)/MailingLists && $(MAKE) mailing-lists.txt +else +%.wml: + @echo "ERROR: Cannot find $(WEBWML) to regenerate the sources. Please read the TODO." endif # Not in Debian's website, therefore kept in our own SVN: diff -Nru doc-debian-4.0.2ubuntu1/doc/social-contract.1.0.txt doc-debian-6.1ubuntu1/doc/social-contract.1.0.txt --- doc-debian-4.0.2ubuntu1/doc/social-contract.1.0.txt 2010-01-11 21:06:50.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/social-contract.1.0.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,118 +0,0 @@ - Version 1.0 ratified on July 5, 1997. Superseded by Version 1.1, - ratified on April 26, 2004. - - Debian, the producers of the Debian GNU/Linux system, have created the - Debian Social Contract. The Debian Free Software Guidelines (DFSG) part - of the contract, initially designed as a set of commitments that we - agree to abide by, has been adopted by the free software community as - the basis of the Open Source Definition. - __________________________________________________________________ - -"Social Contract" with the Free Software Community - - 1. Debian Will Remain 100% Free Software - We promise to keep the Debian GNU/Linux Distribution entirely free - software. As there are many definitions of free software, we - include the guidelines we use to determine if software is "free" - below. We will support our users who develop and run non-free - software on Debian, but we will never make the system depend on an - item of non-free software. - 2. We Will Give Back to the Free Software Community - When we write new components of the Debian system, we will license - them as free software. We will make the best system we can, so that - free software will be widely distributed and used. We will feed - back bug-fixes, improvements, user requests, etc. to the "upstream" - authors of software included in our system. - 3. We Won't Hide Problems - We will keep our entire bug-report database open for public view at - all times. Reports that users file on-line will immediately become - visible to others. - 4. Our Priorities are Our Users and Free Software - We will be guided by the needs of our users and the free-software - community. We will place their interests first in our priorities. - We will support the needs of our users for operation in many - different kinds of computing environment. We won't object to - commercial software that is intended to run on Debian systems, and - we'll allow others to create value-added distributions containing - both Debian and commercial software, without any fee from us. To - support these goals, we will provide an integrated system of - high-quality, 100% free software, with no legal restrictions that - would prevent these kinds of use. - 5. Programs That Don't Meet Our Free-Software Standards - We acknowledge that some of our users require the use of programs - that don't conform to the Debian Free Software Guidelines. We have - created "contrib" and "non-free" areas in our FTP archive for this - software. The software in these directories is not part of the - Debian system, although it has been configured for use with Debian. - We encourage CD manufacturers to read the licenses of software - packages in these directories and determine if they can distribute - that software on their CDs. Thus, although non-free software isn't - a part of Debian, we support its use, and we provide infrastructure - (such as our bug-tracking system and mailing lists) for non-free - software packages. - __________________________________________________________________ - -The Debian Free Software Guidelines (DFSG) - - 1. Free Redistribution - The license of a Debian component may not restrict any party from - selling or giving away the software as a component of an aggregate - software distribution containing programs from several different - sources. The license may not require a royalty or other fee for - such sale. - 2. Source Code - The program must include source code, and must allow distribution - in source code as well as compiled form. - 3. Derived Works - The license must allow modifications and derived works, and must - allow them to be distributed under the same terms as the license of - the original software. - 4. Integrity of The Author's Source Code - The license may restrict source-code from being distributed in - modified form _only_ if the license allows the distribution of - "patch files" with the source code for the purpose of modifying the - program at build time. The license must explicitly permit - distribution of software built from modified source code. The - license may require derived works to carry a different name or - version number from the original software. (This is a compromise. - The Debian group encourages all authors not to restrict any files, - source or binary, from being modified.) - 5. No Discrimination Against Persons or Groups - The license must not discriminate against any person or group of - persons. - 6. No Discrimination Against Fields of Endeavor - The license must not restrict anyone from making use of the program - in a specific field of endeavor. For example, it may not restrict - the program from being used in a business, or from being used for - genetic research. - 7. Distribution of License - The rights attached to the program must apply to all to whom the - program is redistributed without the need for execution of an - additional license by those parties. - 8. License Must Not Be Specific to Debian - The rights attached to the program must not depend on the program's - being part of a Debian system. If the program is extracted from - Debian and used or distributed without Debian but otherwise within - the terms of the program's license, all parties to whom the program - is redistributed should have the same rights as those that are - granted in conjunction with the Debian system. - 9. License Must Not Contaminate Other Software - The license must not place restrictions on other software that is - distributed along with the licensed software. For example, the - license must not insist that all other programs distributed on the - same medium must be free software. - 10. Example Licenses - The "GPL", "BSD", and "Artistic" licenses are examples of licenses - that we consider "free". - - The concept of stating our "social contract with the free software - community" was suggested by Ean Schuessler. This document was drafted - by Bruce Perens, refined by the other Debian developers during a - month-long e-mail conference in June 1997, and then accepted as the - publicly stated policy of the Debian Project. - - Bruce Perens later removed the Debian-specific references from the - Debian Free Software Guidelines to create "The Open Source Definition". - - Other organizations may derive from and build on this document. Please - give credit to the Debian project if you do. diff -Nru doc-debian-4.0.2ubuntu1/doc/social-contract.1.0.wml doc-debian-6.1ubuntu1/doc/social-contract.1.0.wml --- doc-debian-4.0.2ubuntu1/doc/social-contract.1.0.wml 2010-01-11 21:06:50.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/social-contract.1.0.wml 2012-10-20 04:09:43.000000000 +0100 @@ -10,7 +10,7 @@ Guidelines (DFSG) part of the contract, initially designed as a set of commitments that we agree to abide by, has been adopted by the free software community as the basis of the -Open Source Definition. +Open Source Definition.

      "Social Contract" with the Free Software Community

      @@ -120,7 +120,7 @@

    • Example Licenses

      The "GPL", "BSD", and - "Artistic" + "Artistic" licenses are examples of licenses that we consider "free". @@ -133,7 +133,7 @@

      Bruce Perens later removed the Debian-specific references from the Debian Free Software Guidelines to create -“The Open +“The Open Source Definition”.

      Other organizations may derive from and build on this document. diff -Nru doc-debian-4.0.2ubuntu1/doc/social-contract.1.1.txt doc-debian-6.1ubuntu1/doc/social-contract.1.1.txt --- doc-debian-4.0.2ubuntu1/doc/social-contract.1.1.txt 2010-01-11 21:05:06.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/social-contract.1.1.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,118 +0,0 @@ - Version 1.0 ratified on July 5, 1997. Superseded by Version 1.1, - ratified on April 26, 2004. - - Debian, the producers of the Debian GNU/Linux system, have created the - Debian Social Contract. The Debian Free Software Guidelines (DFSG) part - of the contract, initially designed as a set of commitments that we - agree to abide by, has been adopted by the free software community as - the basis of the Open Source Definition. - __________________________________________________________________ - -"Social Contract" with the Free Software Community - - 1. Debian Will Remain 100% Free Software - We promise to keep the Debian GNU/Linux Distribution entirely free - software. As there are many definitions of free software, we - include the guidelines we use to determine if software is "free" - below. We will support our users who develop and run non-free - software on Debian, but we will never make the system depend on an - item of non-free software. - 2. We Will Give Back to the Free Software Community - When we write new components of the Debian system, we will license - them as free software. We will make the best system we can, so that - free software will be widely distributed and used. We will feed - back bug-fixes, improvements, user requests, etc. to the "upstream" - authors of software included in our system. - 3. We Won't Hide Problems - We will keep our entire bug-report database open for public view at - all times. Reports that users file on-line will immediately become - visible to others. - 4. Our Priorities are Our Users and Free Software - We will be guided by the needs of our users and the free-software - community. We will place their interests first in our priorities. - We will support the needs of our users for operation in many - different kinds of computing environment. We won't object to - commercial software that is intended to run on Debian systems, and - we'll allow others to create value-added distributions containing - both Debian and commercial software, without any fee from us. To - support these goals, we will provide an integrated system of - high-quality, 100% free software, with no legal restrictions that - would prevent these kinds of use. - 5. Programs That Don't Meet Our Free-Software Standards - We acknowledge that some of our users require the use of programs - that don't conform to the Debian Free Software Guidelines. We have - created "contrib" and "non-free" areas in our FTP archive for this - software. The software in these directories is not part of the - Debian system, although it has been configured for use with Debian. - We encourage CD manufacturers to read the licenses of software - packages in these directories and determine if they can distribute - that software on their CDs. Thus, although non-free software isn't - a part of Debian, we support its use, and we provide infrastructure - (such as our bug-tracking system and mailing lists) for non-free - software packages. - __________________________________________________________________ - -The Debian Free Software Guidelines (DFSG) - - 1. Free Redistribution - The license of a Debian component may not restrict any party from - selling or giving away the software as a component of an aggregate - software distribution containing programs from several different - sources. The license may not require a royalty or other fee for - such sale. - 2. Source Code - The program must include source code, and must allow distribution - in source code as well as compiled form. - 3. Derived Works - The license must allow modifications and derived works, and must - allow them to be distributed under the same terms as the license of - the original software. - 4. Integrity of The Author's Source Code - The license may restrict source-code from being distributed in - modified form _only_ if the license allows the distribution of - "patch files" with the source code for the purpose of modifying the - program at build time. The license must explicitly permit - distribution of software built from modified source code. The - license may require derived works to carry a different name or - version number from the original software. (This is a compromise. - The Debian group encourages all authors not to restrict any files, - source or binary, from being modified.) - 5. No Discrimination Against Persons or Groups - The license must not discriminate against any person or group of - persons. - 6. No Discrimination Against Fields of Endeavor - The license must not restrict anyone from making use of the program - in a specific field of endeavor. For example, it may not restrict - the program from being used in a business, or from being used for - genetic research. - 7. Distribution of License - The rights attached to the program must apply to all to whom the - program is redistributed without the need for execution of an - additional license by those parties. - 8. License Must Not Be Specific to Debian - The rights attached to the program must not depend on the program's - being part of a Debian system. If the program is extracted from - Debian and used or distributed without Debian but otherwise within - the terms of the program's license, all parties to whom the program - is redistributed should have the same rights as those that are - granted in conjunction with the Debian system. - 9. License Must Not Contaminate Other Software - The license must not place restrictions on other software that is - distributed along with the licensed software. For example, the - license must not insist that all other programs distributed on the - same medium must be free software. - 10. Example Licenses - The "GPL", "BSD", and "Artistic" licenses are examples of licenses - that we consider "free". - - The concept of stating our "social contract with the free software - community" was suggested by Ean Schuessler. This document was drafted - by Bruce Perens, refined by the other Debian developers during a - month-long e-mail conference in June 1997, and then accepted as the - publicly stated policy of the Debian Project. - - Bruce Perens later removed the Debian-specific references from the - Debian Free Software Guidelines to create "The Open Source Definition". - - Other organizations may derive from and build on this document. Please - give credit to the Debian project if you do. diff -Nru doc-debian-4.0.2ubuntu1/doc/social-contract.1.1.wml doc-debian-6.1ubuntu1/doc/social-contract.1.1.wml --- doc-debian-4.0.2ubuntu1/doc/social-contract.1.1.wml 2010-01-11 21:05:06.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/social-contract.1.1.wml 1970-01-01 01:00:00.000000000 +0100 @@ -1,140 +0,0 @@ - - -

      - Version 1.0 ratified on July 5, 1997. Superseded by - Version 1.1, ratified on April 26, 2004. -

      - -

      Debian, the producers of the Debian GNU/Linux system, have created the -Debian Social Contract. The Debian Free Software -Guidelines (DFSG) part of the contract, initially designed -as a set of commitments that we agree to abide by, has been adopted by -the free software community as the basis of the -Open Source Definition. - -

      -

      "Social Contract" with the Free Software Community

      -
        -

      1. Debian Will Remain 100% Free Software -

        We promise to keep the Debian GNU/Linux Distribution - entirely free software. As there are many definitions of - free software, we include the guidelines we use to determine - if software is "free" below. We will support our - users who develop and run non-free software on Debian, but - we will never make the system depend on an item of non-free - software.

        -
      2. We Will Give Back to the Free Software Community -

        When we write new components of the Debian system, we will - license them as free software. We will make the best system - we can, so that free software will be widely distributed and - used. We will feed back bug-fixes, improvements, user - requests, etc. to the "upstream" authors of software - included in our system.

        -

      3. We Won't Hide Problems -

        We will keep our entire bug-report database open for public - view at all times. Reports that users file on-line will - immediately become visible to others.

        -

      4. Our Priorities are Our Users and Free Software -

        We will be guided by the needs of our users and the - free-software community. We will place their interests first - in our priorities. We will support the needs of our users - for operation in many different kinds of computing - environment. We won't object to commercial software that is - intended to run on Debian systems, and we'll allow others to - create value-added distributions containing both Debian and - commercial software, without any fee from us. To support - these goals, we will provide an integrated system of - high-quality, 100% free software, with no legal restrictions - that would prevent these kinds of use.

        -

      5. Programs That Don't Meet Our Free-Software Standards -

        We acknowledge that some of our users require the use of - programs that don't conform to the - Debian Free Software Guidelines. - We have created "contrib" and "non-free" - areas in our FTP archive for this software. The software in - these directories is not part of the Debian system, although - it has been configured for use with Debian. We encourage CD - manufacturers to read the licenses of software packages in - these directories and determine if they can distribute that - software on their CDs. Thus, although non-free software - isn't a part of Debian, we support its use, and we provide - infrastructure (such as our bug-tracking system and mailing - lists) for non-free software packages. -

      -
      -

      The Debian Free Software Guidelines (DFSG)

      -
        -

      1. Free Redistribution -

        The license of a Debian component may not restrict any - party from selling or giving away the software as a - component of an aggregate software distribution containing - programs from several different sources. The license may not - require a royalty or other fee for such sale.

        -

      2. Source Code -

        The program must include source code, and must allow - distribution in source code as well as compiled - form.

        -

      3. Derived Works -

        The license must allow modifications and derived works, and - must allow them to be distributed under the same terms as - the license of the original software.

        -

      4. Integrity of The Author's Source Code -

        The license may restrict source-code from being distributed - in modified form _only_ if the license allows - the distribution of "patch files" with the source - code for the purpose of modifying the program at build - time. The license must explicitly permit distribution of - software built from modified source code. The license may - require derived works to carry a different name or version - number from the original software. (This is a - compromise. The Debian group encourages all authors not to - restrict any files, source or binary, from being - modified.)

        -

      5. No Discrimination Against Persons or Groups -

        The license must not discriminate against any person or - group of persons.

        -

      6. No Discrimination Against Fields of Endeavor -

        The license must not restrict anyone from making use of the - program in a specific field of endeavor. For example, it may - not restrict the program from being used in a business, or - from being used for genetic research.

        -

      7. Distribution of License -

        The rights attached to the program must apply to all to - whom the program is redistributed without the need for - execution of an additional license by those - parties.

        -

      8. License Must Not Be Specific to Debian -

        The rights attached to the program must not depend on the - program's being part of a Debian system. If the program is - extracted from Debian and used or distributed without Debian - but otherwise within the terms of the program's license, all - parties to whom the program is redistributed should have the - same rights as those that are granted in conjunction with - the Debian system.

        -

      9. License Must Not Contaminate Other Software -

        The license must not place restrictions on other software - that is distributed along with the licensed - software. For example, the license must not insist that all - other programs distributed on the same medium must be free - software.

        -

      10. Example Licenses -

        The "GPL", - "BSD", and - "Artistic" - licenses are examples of licenses that we consider "free". -

      - -

      The concept of stating our "social contract with the free -software community" was suggested by Ean Schuessler. This document -was drafted by Bruce Perens, refined by the other Debian developers -during a month-long e-mail conference in June 1997, and then -\ -accepted as the publicly stated policy of the Debian Project.

      - -

      Bruce Perens later removed the Debian-specific references from the -Debian Free Software Guidelines to create -“The Open -Source Definition”.

      - -

      Other organizations may derive from and build on this document. -Please give credit to the Debian project if you do. diff -Nru doc-debian-4.0.2ubuntu1/doc/social-contract.txt doc-debian-6.1ubuntu1/doc/social-contract.txt --- doc-debian-4.0.2ubuntu1/doc/social-contract.txt 2010-01-11 21:06:49.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/social-contract.txt 1970-01-01 01:00:00.000000000 +0100 @@ -1,120 +0,0 @@ - Version 1.1 ratified on April 26, 2004. Supersedes Version 1.0 ratified - on July 5, 1997. - - Debian, the producers of the Debian GNU/Linux system, have created the - Debian Social Contract. The Debian Free Software Guidelines (DFSG) part - of the contract, initially designed as a set of commitments that we - agree to abide by, has been adopted by the free software community as - the basis of the Open Source Definition. - __________________________________________________________________ - -"Social Contract" with the Free Software Community - - 1. Debian will remain 100% free - We provide the guidelines that we use to determine if a work is - "free" in the document entitled "The Debian Free Software - Guidelines". We promise that the Debian system and all its - components will be free according to these guidelines. We will - support people who create or use both free and non-free works on - Debian. We will never make the system require the use of a non-free - component. - 2. We will give back to the free software community - When we write new components of the Debian system, we will license - them in a manner consistent with the Debian Free Software - Guidelines. We will make the best system we can, so that free works - will be widely distributed and used. We will communicate things - such as bug fixes, improvements and user requests to the "upstream" - authors of works included in our system. - 3. We will not hide problems - We will keep our entire bug report database open for public view at - all times. Reports that people file online will promptly become - visible to others. - 4. Our priorities are our users and free software - We will be guided by the needs of our users and the free software - community. We will place their interests first in our priorities. - We will support the needs of our users for operation in many - different kinds of computing environments. We will not object to - non-free works that are intended to be used on Debian systems, or - attempt to charge a fee to people who create or use such works. We - will allow others to create distributions containing both the - Debian system and other works, without any fee from us. In - furtherance of these goals, we will provide an integrated system of - high-quality materials with no legal restrictions that would - prevent such uses of the system. - 5. Works that do not meet our free software standards - We acknowledge that some of our users require the use of works that - do not conform to the Debian Free Software Guidelines. We have - created "contrib" and "non-free" areas in our archive for these - works. The packages in these areas are not part of the Debian - system, although they have been configured for use with Debian. We - encourage CD manufacturers to read the licenses of the packages in - these areas and determine if they can distribute the packages on - their CDs. Thus, although non-free works are not a part of Debian, - we support their use and provide infrastructure for non-free - packages (such as our bug tracking system and mailing lists). - __________________________________________________________________ - -The Debian Free Software Guidelines (DFSG) - - 1. Free Redistribution - The license of a Debian component may not restrict any party from - selling or giving away the software as a component of an aggregate - software distribution containing programs from several different - sources. The license may not require a royalty or other fee for - such sale. - 2. Source Code - The program must include source code, and must allow distribution - in source code as well as compiled form. - 3. Derived Works - The license must allow modifications and derived works, and must - allow them to be distributed under the same terms as the license of - the original software. - 4. Integrity of The Author's Source Code - The license may restrict source-code from being distributed in - modified form _only_ if the license allows the distribution of - "patch files" with the source code for the purpose of modifying the - program at build time. The license must explicitly permit - distribution of software built from modified source code. The - license may require derived works to carry a different name or - version number from the original software. (This is a compromise. - The Debian group encourages all authors not to restrict any files, - source or binary, from being modified.) - 5. No Discrimination Against Persons or Groups - The license must not discriminate against any person or group of - persons. - 6. No Discrimination Against Fields of Endeavor - The license must not restrict anyone from making use of the program - in a specific field of endeavor. For example, it may not restrict - the program from being used in a business, or from being used for - genetic research. - 7. Distribution of License - The rights attached to the program must apply to all to whom the - program is redistributed without the need for execution of an - additional license by those parties. - 8. License Must Not Be Specific to Debian - The rights attached to the program must not depend on the program's - being part of a Debian system. If the program is extracted from - Debian and used or distributed without Debian but otherwise within - the terms of the program's license, all parties to whom the program - is redistributed should have the same rights as those that are - granted in conjunction with the Debian system. - 9. License Must Not Contaminate Other Software - The license must not place restrictions on other software that is - distributed along with the licensed software. For example, the - license must not insist that all other programs distributed on the - same medium must be free software. - 10. Example Licenses - The "GPL", "BSD", and "Artistic" licenses are examples of licenses - that we consider "free". - - The concept of stating our "social contract with the free software - community" was suggested by Ean Schuessler. This document was drafted - by Bruce Perens, refined by the other Debian developers during a - month-long e-mail conference in June 1997, and then accepted as the - publicly stated policy of the Debian Project. - - Bruce Perens later removed the Debian-specific references from the - Debian Free Software Guidelines to create "The Open Source Definition". - - Other organizations may derive from and build on this document. Please - give credit to the Debian project if you do. diff -Nru doc-debian-4.0.2ubuntu1/doc/social-contract.wml doc-debian-6.1ubuntu1/doc/social-contract.wml --- doc-debian-4.0.2ubuntu1/doc/social-contract.wml 2010-01-11 21:06:49.000000000 +0000 +++ doc-debian-6.1ubuntu1/doc/social-contract.wml 2012-10-20 04:09:43.000000000 +0100 @@ -1,16 +1,21 @@ +{#meta#: + +:#meta#} +

      Version 1.1 ratified on April 26, 2004. Supersedes Version 1.0 ratified on July 5, 1997.

      -

      Debian, the producers of the Debian GNU/Linux system, have created the +

      Debian, the producers of the Debian system, have created the Debian Social Contract. The Debian Free Software Guidelines (DFSG) part of the contract, initially designed as a set of commitments that we agree to abide by, has been adopted by the free software community as the basis of the -Open Source Definition.

      +Open Source Definition.

      Social Contract with the Free Software Community

      @@ -138,7 +143,7 @@

    • Example Licenses

      The GPL, BSD, and - Artistic + Artistic licenses are examples of licenses that we consider free.

      • @@ -151,7 +156,7 @@

      Bruce Perens later removed the Debian-specific references from the Debian Free Software Guidelines to create -The Open +The Open Source Definition.

      Other organizations may derive from and build on this document. diff -Nru doc-debian-4.0.2ubuntu1/doc/source-unpack.txt doc-debian-6.1ubuntu1/doc/source-unpack.txt --- doc-debian-4.0.2ubuntu1/doc/source-unpack.txt 2008-04-29 01:59:56.000000000 +0100 +++ doc-debian-6.1ubuntu1/doc/source-unpack.txt 2012-10-20 04:09:43.000000000 +0100 @@ -1,33 +1,68 @@ HOW TO UNPACK A DEBIAN SOURCE PACKAGE -There are two kinds of Debian source packages: old ones and new ones. +If you have `dpkg-source', you can use it to unpack any Debian source +package: put all the files in the same directory and type `dpkg-source +-x .dsc'. The remainder of this document explains how to +unpack Debian source packages on non-Debian systems, or on Debian +systems without the `dpkg-dev' package installed. + +There are several kinds of Debian source packages, identified by the +Format: field in the .dsc file. If there is no Format: field, treat +it as "1.0". + + +"1.0" packages can be either native or non-native. Native packages +(where the Debian source is the upstream source) look like this: + hello_1.3.dsc + hello_1.3.tar.gz +To unpack this kind of package, just untar the .tar.gz file. -A. Old ones look like this: - hello-1.3-4.tar.gz - hello-1.3-4.diff.gz - You unpack them by untarring the .tar.gz. There is NO need to apply - the diff. - -B. New ones look like this: +Non-native "1.0" packages look like this: hello_1.3-11.dsc hello_1.3-11.diff.gz - hello_1.3-11.orig.tar.gz - note the `.orig' part - Here you MUST use dpkg-source or apply the diff manually - see below. - - If you have `dpkg-source' you should put the files in the same - directory and type `dpkg-source -x .dsc'. + hello_1.3.orig.tar.gz - note the `.orig' part - If you do not you can extract the Debian source as follows: 1. untar P_V.orig.tar.gz. 2. rename the resulting P-V.orig directory to P-V. If some other directory results, rename *it* to P-V. 3. mkdir P-V/debian. 4. apply the diff with patch -p0. 5. do `chmod +x P-V/debian/rules' - (where P is the package name and V the version.) + (where P is the package name and V the upstream version - `hello' and + `1.3' respectively in this example.) + + +"3.0 (native)" packages are the same as native "1.0" packages, except +that the source tarball may be compressed using methods other than +gzip. + + +"3.0 (quilt)" packages look like this: + hello_1.3-11.dsc + hello_1.3-11.debian.tar.gz + hello_1.3.orig.tar.gz + hello_1.3.orig-COMPONENT.tar.gz + (optional, for one or more values of COMPONENT) +The compressed files may be compressed using methods other than gzip. + +To unpack this kind of package, you will need to install `quilt' +(http://savannah.nongnu.org/projects/quilt), then: + 1. untar P_V.orig.tar.gz. + 2. rename the resulting P-V.orig directory to P-V. If some other + directory results, rename *it* to P-V. + 3. if there are any orig-COMPONENT tarballs, untar each of them to + P-V/COMPONENT. + 4. remove P-V/debian if it exists. + 5. change to the P-V directory. + 6. untar P_V-R.debian.tar.gz; it will unpack to a `debian' + subdirectory. + 7. run `QUILT_PATCHES=debian/patches quilt push -a'. + (where P is the package name, V the upstream version, and R the + Debian revision - `hello', `1.3', and `11' in this example.) + -C. There are some packages where the Debian source is the upstream - source. In this case there will be no .diff.gz and you can just use - the .tar.gz. If a .dsc is provided you can use `dpkg-source -x'. +See the dpkg-source(1) manual page for full details of all formats, +including experimental ones. -- Ian Jackson Sat, 31 Aug 1996 + -- Colin Watson Sun, 17 Oct 2010 diff -Nru doc-debian-4.0.2ubuntu1/doc-base/debian-constitution-text doc-debian-6.1ubuntu1/doc-base/debian-constitution-text --- doc-debian-4.0.2ubuntu1/doc-base/debian-constitution-text 2008-04-29 02:00:01.000000000 +0100 +++ doc-debian-6.1ubuntu1/doc-base/debian-constitution-text 1970-01-01 01:00:00.000000000 +0100 @@ -1,11 +0,0 @@ -Document: debian-constitution-text -Title: Debian Constitution -Author: The Debian Project -Abstract: This document contains the complete text of Debian Project - Constitution (v1.2), in text format. Version 1.2 ratified on October - 29th, 2003. Supersedes Version 1.1 ratified on June 21st, 2003, - which itself supersedes Version 1.0 ratified on December 2nd, 1998 -Section: Debian - -Format: text -Files: /usr/share/doc/debian/constitution.txt diff -Nru doc-debian-4.0.2ubuntu1/doc-base/debian-mailing-lists doc-debian-6.1ubuntu1/doc-base/debian-mailing-lists --- doc-debian-4.0.2ubuntu1/doc-base/debian-mailing-lists 2008-04-29 02:00:01.000000000 +0100 +++ doc-debian-6.1ubuntu1/doc-base/debian-mailing-lists 1970-01-01 01:00:00.000000000 +0100 @@ -1,8 +0,0 @@ -Document: debian-mailing-lists -Title: Debian mailing lists -Author: Debian Listmasters -Abstract: A comprehensive list of all mailing lists at lists.debian.org -Section: Debian - -Format: text -Files: /usr/share/doc/debian/mailing-lists.txt diff -Nru doc-debian-4.0.2ubuntu1/doc-base/debian-manifesto doc-debian-6.1ubuntu1/doc-base/debian-manifesto --- doc-debian-4.0.2ubuntu1/doc-base/debian-manifesto 2008-04-29 02:00:01.000000000 +0100 +++ doc-debian-6.1ubuntu1/doc-base/debian-manifesto 1970-01-01 01:00:00.000000000 +0100 @@ -1,8 +0,0 @@ -Document: debian-manifesto -Title: The Debian Manifesto -Author: Ian A. Murdock -Abstract: This document is provided in order to document Debian's history. -Section: Debian - -Format: text -Files: /usr/share/doc/debian/debian-manifesto diff -Nru doc-debian-4.0.2ubuntu1/doc-base/debian-reporting-bugs doc-debian-6.1ubuntu1/doc-base/debian-reporting-bugs --- doc-debian-4.0.2ubuntu1/doc-base/debian-reporting-bugs 2008-04-29 02:00:01.000000000 +0100 +++ doc-debian-6.1ubuntu1/doc-base/debian-reporting-bugs 1970-01-01 01:00:00.000000000 +0100 @@ -1,8 +0,0 @@ -Document: debian-reporting-bugs -Title: How to report a bug in Debian -Author: Ian Jackson, Steven Brenner and Darren Benham -Abstract: Description on how to properly report a bug in Debian GNU/Linux. -Section: Debian - -Format: text -Files: /usr/share/doc/debian/bug-reporting.txt diff -Nru doc-debian-4.0.2ubuntu1/doc-base/debian-social-contract doc-debian-6.1ubuntu1/doc-base/debian-social-contract --- doc-debian-4.0.2ubuntu1/doc-base/debian-social-contract 2008-04-29 02:00:01.000000000 +0100 +++ doc-debian-6.1ubuntu1/doc-base/debian-social-contract 1970-01-01 01:00:00.000000000 +0100 @@ -1,11 +0,0 @@ -Document: debian-social-contract -Title: The Debian Social Contract, and the Debian Free Software Guidelines -Author: The Debian Project -Abstract: This is the "social contract" (v1.1) we offer to the free software - community. The Debian Free Software Guidelines (DFGS) are the set of - license conditions to be met for packages to be part of the Debian system. - The version 1.1 supersedes version 1.0, ratified on April 5, 1997. -Section: Debian - -Format: text -Files: /usr/share/doc/debian/social-contract.txt diff -Nru doc-debian-4.0.2ubuntu1/README.build doc-debian-6.1ubuntu1/README.build --- doc-debian-4.0.2ubuntu1/README.build 1970-01-01 01:00:00.000000000 +0100 +++ doc-debian-6.1ubuntu1/README.build 2012-10-17 21:56:40.000000000 +0100 @@ -0,0 +1,30 @@ + +- The documents under doc/ can be auto-updated if you have a local + website CVS copy. It currently only works for english but + could be easily expanded to provide all translations. Do we + want to do this or should this be handled by the doc-debian-XX + packages ? + + Note: some of the doc-debian-XX packages are really out of date + and don't provide the same content that is available in doc-debian + +---------------------------------------------------------------- +Javier Fernandez-Sanguino +Last updated: Wed, 02 Apr 2008 08:03:00 +0200 + + + +Build instructions: + + root@nagy:~# aptitude update && aptitude -V install wml + + joostvb@nagy:~/debian% ln -s ../cvs/cvs.debian.org/webwml www + + joostvb@nagy:~/sv...ackages/trunk/doc-debian% cat ~/bin/svn-prebuild + #!/bin/sh + test -d $buildArea/doc-debian-3.1.6/doc || mkdir -p $buildArea/doc-debian-3.1.6/doc + cp doc/Makefile $buildArea/doc-debian-3.1.6/doc + make -C $buildArea/doc-debian-3.1.6/doc + + svn-buildpackage -uc -us -rfakeroot --svn-ignore --svn-dont-purge --svn-lintian --svn-linda --svn-prebuild=svn-prebuild --svn-reuse + diff -Nru doc-debian-4.0.2ubuntu1/TODO doc-debian-6.1ubuntu1/TODO --- doc-debian-4.0.2ubuntu1/TODO 2008-04-29 02:00:04.000000000 +0100 +++ doc-debian-6.1ubuntu1/TODO 1970-01-01 01:00:00.000000000 +0100 @@ -1,29 +0,0 @@ - -- The documents under doc/ can be auto-updated if you have a local - website CVS copy. It currently only works for english but - could be easily expanded to provide all translations. Do we - want to do this or should this be handled by the doc-debian-XX - packages - Note: some of the doc-debian-XX packages are really out of date - and don't provide the same content that is available in doc-debian - ----------------------------------------------------------------- -Javier Fernandez-Sanguino -Last updated: Wed, 02 Apr 2008 08:03:00 +0200 - - - -Build instructions: - - root@nagy:~# aptitude update && aptitude -V install wml - - joostvb@nagy:~/debian% ln -s ../cvs/cvs.debian.org/webwml www - - joostvb@nagy:~/sv...ackages/trunk/doc-debian% cat ~/bin/svn-prebuild - #!/bin/sh - test -d $buildArea/doc-debian-3.1.6/doc || mkdir -p $buildArea/doc-debian-3.1.6/doc - cp doc/Makefile $buildArea/doc-debian-3.1.6/doc - make -C $buildArea/doc-debian-3.1.6/doc - - svn-buildpackage -uc -us -rfakeroot --svn-ignore --svn-dont-purge --svn-lintian --svn-linda --svn-prebuild=svn-prebuild --svn-reuse -