web/deps/dep0.mdwn

[[!meta title="DEP-0: Introducing Debian Enhancement Proposals (DEPs)"]]

    Title: Introducing Debian Enhancement Proposals (DEPs)
    DEP: 0
    State: CANDIDATE
    Date: 2009-07-26
    Drivers: Stefano Zacchiroli <zack@debian.org>,
     Adeodato Simó <dato@net.com.org.es>,
     Lars Wirzenius <liw@iki.fi>
    URL: http://dep.debian.net/deps/dep0
    Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep0.mdwn
    License: http://www.jclark.com/xml/copying.txt
    Abstract:
     Workflow for managing discussions about improvements to Debian
     and archiving their outcomes.


Introduction
------------

This is a proposal to organize discussions about Debian enhancements,
reflect their current status and, in particular, to archive their
outcomes, via a new lightweight process based on Debian Enhancement
Proposals (DEPs). This idea is loosely based on existing similar systems
such as RFCs and Python PEPs. It is also completely opt-in, and does not
involve any new committees, powers, or authorities.


Motivation
----------

Currently, when having discussions about improvements to Debian, it is
not always clear when consensus has been reached, and people willing to
implement it may start too early, leading to wasted efforts, or delay it
indefinitely, because there's not clear indication it is time to begin. At the
same time, potential adopters of an enhancement may not be able to
easily assess whether they should use said implementation or not,
because it's difficult to know whether it adjusts to the consensus
reached during the discussion period.

Our normative documents rely on wide adoption of a practice before
documenting it, and adopters can be reluctant to make use of it before a
clear indication that a practice has some consensus behind it. This
creates a hard to break loop that this process hopes to alleviate, by
providing a mechanism to reflect the status of each proposal, including
whether it has reached consensus or not.

Secondly, we lack at the moment a central index in which to list such
proposals, which would be useful to see at a glance what open fronts
there are at a given moment in Debian, and who is taking care of them
and, additionally, to serve as a storage place for successfully
completed proposals, documenting the outcome of the discussion and the
details of the implementation.

By using this process, people involved in developing any enhancement can
help to build such index, with very little overhead required on their
part.


Workflow
--------

A "Debian enhancement" can be pretty much any change to Debian,
technical or otherwise. Examples of situations when the DEP process
might be or might have been used include:

* Introducing new debian/control fields (Homepage, Vcs-*).
* Making debian/copyright be machine parseable.
* Agreeing upon a meta-package name or virtual package name.
* Deciding on a procedure for the Debconf team for assigning travel
  sponsorship money.
* Formalizing existing informal processes or procedures, e.g.,
  the procedure for getting a new architecture added to the archive, or
  getting access to piatti.debian.org to run QA tests.

The workflow is very simple, and is intended to be quite lightweight:
an enhancement to Debian is suggested, discussed, implemented, and
becomes accepted practice (or policy, if applicable), in the normal
Debian way. As the discussion progresses, the enhancement is assigned
certain states, as explained below. During all the process, a single URL
maintained by the proposers can be used to check the status of the
proposal.

The result of all this is:

  1. an implementation of the enhancement and
  2. a document that can be referred to later on without having to dig
     up and read through large discussions.

The actual discussions should happen in the usual forum or forums for
the topic of the DEP. This way, DEPs do not act as yet another forum to
be followed. For example, a DEP suggesting changes to www.debian.org
graphical design should happen on debian-www, as usual.

In the same way, DEPs do not give any extra powers or authority to
anyone: they rely on reaching consensus in the traditional Debian way,
by engaging in discussions on mailing lists, IRC, or real life meetings
as appropriate, and not by consulting an external body for a decision.
To be acceptable, this consensus includes agreement from affected
parties, including those who would have to implement it or accept an
implementation.

The person or people who do the suggestion are the "drivers" of the
proposal and have the responsibility of writing the initial draft, and
of updating it during the discussions, see below.


Proposal states
---------------

<div style="float: right; text-align: center;">
[[!img deps/dep0/workflow.png size="500x250" alt="DEP state diagram"]]
<br />
<span style="font-size: xx-small">DEP workflow: state diagram</span>
</div>
A given DEP can be in one of the following *states*:

* DRAFT
* CANDIDATE
* ACCEPTED
* REJECTED
* OBSOLETE

The ideal progression of states is DRAFT -> CANDIDATE -> ACCEPTED, but
reality requires a couple of other states and transitions as well.

### DRAFT state: discussion

* every new proposal starts as a DRAFT
* anyone can propose a draft
* each draft has a number (next free one from document index)
* normal discussion and changes to the text happen in this state
* drafts should include *extra* criteria for success (in addition to
  having obtained consensus, see below), that is, requirements to
  finally become ACCEPTED

#### DRAFT -> CANDIDATE: rough consensus

In order for a DEP to become CANDIDATE, the following condition should
be met:

* consensus exists for *what* should be done, and *how* it should be
  done (agreement needs to be expressed by all affected parties, not
  just the drivers; silence is not agreement, but unanimity is not
  required, either)

### CANDIDATE: implementation + testing

The CANDIDATE state is meant to prove, via a suitable implementation
and its testing, that a given DEP is feasible.

* of course, implementation can start in earlier states
* changes to the text can happen also in this period, primarily based
  on feedback from implementation
* this period must be long enough that there is consensus that the
  enhancement works (on the basis of implementation evaluation)
* since DEP are not necessarily technical, "implementation" does not
  necessarily mean coding

#### CANDIDATE -> ACCEPTED: working implementation

In order for a DEP to become ACCEPTED, the following condition should
be met:

* consensus exists that the implementation has been a success

### ACCEPTED: have fun

Once accepted:

* the final version of the DEP text is archived on
  <http://dep.debian.net> for future reference
* if applicable, the proposed DEP change is integrated into
  authoritative texts such as policy, developer's reference, etc.

#### {DRAFT, CANDIDATE} -> REJECTED

A DEP can become REJECTED in the following cases:

* the drivers are no longer interested in pursuing the DEP and
  explicitly acknowledge so
* there are no modifications to a DEP in DRAFT state for 6 months or
  more
* there is no consensus either on the draft text or on the fact that
  the implementation is working satisfactorily

#### ACCEPTED -> OBSOLETE: no longer relevant

A DEP can become OBSOLETE when it is no longer relevant, for example:

* a new DEP gets accepted overriding previous DEPs (in that case the
  new DEP should refer to the one it OBSOLETE-s)
* the object of the enhancement is no longer in use

### {REJECTED, OBSOLETE}

In one of these states, no further actions are needed.

It is recommended that DEPs in one of these states carry a reason
describing why they have moved to such a state.


What the drivers should do
--------------------------

The only additional burden of the DEP process falls on the shoulders of its
drivers. They have to take care of all the practical work of writing
and maintaining the text, so that everyone else can just continue
discussing things as before.  Driver's burden can be summarized as:

* Write the draft text and update it during discussion.
* Determine when (rough) consensus in discussion has been reached.
* Implement, or find volunteers to implement.
* Determine when consensus of implementation success has been reached,
  when the testing of the available implementation has been satisfactory.
* Update the DEP with progress updates at suitable intervals, until the
  DEP has been accepted (or rejected).

If the drivers go missing in action, other people may step in and
courteously take over the driving position.

**Note**: the drivers can of course participate in the discussion as
everybody else, but have no special authority to impose their ideas to
others. <q>DEP gives pencils, not hammers.</q>


Format and content
------------------

A DEP is basically a free-form plain text file, except that it must
start with a paragraph of the following RFC822-style headers:

* Title: the full title of the document
* DEP: the number for this DEP
* State: the current state of this revision
* Date: the date of this revision
* Drivers: a list of drivers (names and e-mail addresses), in RFC822
  syntax for the To: header
* URL: during DRAFT state, a link to the canonical place of the draft
  (typically probably http://wiki.debian.org/DEP/DEPxxx or
  http://dep.debian.net/deps/depXXX)
* Source: one or more URLs to browse the sources used to produce the displayed
  version of the DEP.
* Abstract: a short paragraph (formatted as the long Description in
  debian/control)

(Additionally, REJECTED DEPs can carry a "Reason:" field describing
why they were rejected.)

The rest of the file is free form. If the DEP is kept in a wiki, using
its markup syntax is, of course, a good idea.

Suggested document contents:

* An introduction, giving an overview of the situation and the motivation
  for the DEP.
* A plan for implementation, especially indicating what parts of Debian need
  to be changed, and preferably indicating who will do the work.
* Preferably a list of criteria to judge whether the implementation has been
  a success.
* Links to mailing list threads, perhaps highlighting particularly important
  messages. If discussion happens on IRC, pointers to logs would be nice.


License
-------

The DEP must have a license that is DFSG free. You may choose the
license freely, but the "Expat" license is recommended. The
official URL for it is <http://www.jclark.com/xml/copying.txt> and
the license text is:

    Copyright (c) <year>  <your names>
    
    Permission is hereby granted, free of charge, to any person obtaining
    a copy of this software and associated documentation files (the
    "Software"), to deal in the Software without restriction, including
    without limitation the rights to use, copy, modify, merge, publish,
    distribute, sublicense, and/or sell copies of the Software, and to
    permit persons to whom the Software is furnished to do so, subject to
    the following conditions:
    
    The above copyright notice and this permission notice shall be included
    in all copies or substantial portions of the Software.
    
    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
    IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
    CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
    TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
    SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The justification for this recommendation is that this license is one
of the most permissive of the well-known licenses. By using this
license, it is easy to copy parts of the DEP to other places, such as
documentation for Debian development or embedded in individual
packages.


Creating a DEP
--------------

The procedure to create a DEP is simple: send an e-mail to
`debian-project@lists.debian.org`, stating that you're taking the next
available number, and including the first paragraph of the DEP as
explained above. It is very important to include the list of drivers,
and the URL where the draft will be kept up to date. The next available
DEP number can be obtained by consulting <http://dep.debian.net>.

It is also a very good idea to mention in this mail the place where the
discussion is going to take place, with a pointer to the thread in the
mailing list archives if it has already started.

Additionally, drivers are welcome to maintain their DEPs, even in the
draft state, in a repository inside the `dep` Alioth project, following
the instructions at <http://dep.debian.net/depdn-howto>. They are free not to
do so, and in that case a DEP0 driver or some interested party will
update the `dep.debian.net` index with their DEP, and a pointer to the
URL they provided.


Revising an accepted DEP
------------------------

If the feature, or whatever, of the DEP needs further changing later,
the process can start over with the accepted version of the DEP document
as the initial draft. The new draft will get a new DEP number. Once the
new DEP is accepted, the old one should move to OBSOLETE state.


License
-------

The following copyright statement and license apply to DEP0 (this
document).

Copyright (c) 2008-2009  Stefano Zacchiroli, Adeodato Simó, Lars Wirzenius

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Changes
-------

* 2012-03-25:
  [ Charles Plessy ]
  * Added a "Source" field, to transfer the VCS information from the index to
    the DEP itself.

* 2009-07-26:
  [ Zack, Dato, Lars]
  * Re-word state description: describe separately states and
    transitions.
  * Rename "DROPPED" status to "REJECTED"; inhibit "resurrection" of
    REJECTED DEPs.
  * Mention that dep.debian.net is the central archival place
  * Stress that DEPs give no special powers to drivers, in the "driver
    role" section
  * Change the state of DEP0 to CANDIDATE

* 2008-06-12:
  [ Lars Wirzenius ]
  * Added a recommendation for the Expat license for new DEPs.
  * Set this DEP to be licensed under the Expat license.

* 2008-05-29:
  [ Lars Wirzenius ]
  * Added section saying that a DEP should have a DFSG free license.

* 2008-01-15:
  [ Adeodato Simó ]
  * Add section about how to create a DEP.
  * Rewrite "Introduction" (splitting "Motivation" off), and parts of
    "Workflow" as well.

  [ Lars Wirzenius ]
  * Typo fixes.

* 2008-01-11: Minor tweaks by Zack (mostly cosmetic, but also
  some more detailed specification of former more vague aspects)

* 2008-01-09: Various cleanups and tweaks by Lars, based on feedback
  from several parties.

* 2007-12-01: Initial version written after some quick brainstorming at
  the QA meeting in Extremadura, Spain, by Stefano, Adeodato, and Lars.

1	[[!meta title="DEP-0: Introducing Debian Enhancement Proposals (DEPs)"]]
2
3	Title: Introducing Debian Enhancement Proposals (DEPs)
4	DEP: 0
5	State: CANDIDATE
6	Date: 2009-07-26
7	Drivers: Stefano Zacchiroli <zack@debian.org>,
8	Adeodato Simó <dato@net.com.org.es>,
9	Lars Wirzenius <liw@iki.fi>
10	URL: http://dep.debian.net/deps/dep0
11	Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep0.mdwn
12	License: http://www.jclark.com/xml/copying.txt
13	Abstract:
14	Workflow for managing discussions about improvements to Debian
15	and archiving their outcomes.
16
17
18	Introduction
19	------------
20
21	This is a proposal to organize discussions about Debian enhancements,
22	reflect their current status and, in particular, to archive their
23	outcomes, via a new lightweight process based on Debian Enhancement
24	Proposals (DEPs). This idea is loosely based on existing similar systems
25	such as RFCs and Python PEPs. It is also completely opt-in, and does not
26	involve any new committees, powers, or authorities.
27
28
29	Motivation
30	----------
31
32	Currently, when having discussions about improvements to Debian, it is
33	not always clear when consensus has been reached, and people willing to
34	implement it may start too early, leading to wasted efforts, or delay it
35	indefinitely, because there's not clear indication it is time to begin. At the
36	same time, potential adopters of an enhancement may not be able to
37	easily assess whether they should use said implementation or not,
38	because it's difficult to know whether it adjusts to the consensus
39	reached during the discussion period.
40
41	Our normative documents rely on wide adoption of a practice before
42	documenting it, and adopters can be reluctant to make use of it before a
43	clear indication that a practice has some consensus behind it. This
44	creates a hard to break loop that this process hopes to alleviate, by
45	providing a mechanism to reflect the status of each proposal, including
46	whether it has reached consensus or not.
47
48	Secondly, we lack at the moment a central index in which to list such
49	proposals, which would be useful to see at a glance what open fronts
50	there are at a given moment in Debian, and who is taking care of them
51	and, additionally, to serve as a storage place for successfully
52	completed proposals, documenting the outcome of the discussion and the
53	details of the implementation.
54
55	By using this process, people involved in developing any enhancement can
56	help to build such index, with very little overhead required on their
57	part.
58
59
60	Workflow
61	--------
62
63	A "Debian enhancement" can be pretty much any change to Debian,
64	technical or otherwise. Examples of situations when the DEP process
65	might be or might have been used include:
66
67	* Introducing new debian/control fields (Homepage, Vcs-*).
68	* Making debian/copyright be machine parseable.
69	* Agreeing upon a meta-package name or virtual package name.
70	* Deciding on a procedure for the Debconf team for assigning travel
71	sponsorship money.
72	* Formalizing existing informal processes or procedures, e.g.,
73	the procedure for getting a new architecture added to the archive, or
74	getting access to piatti.debian.org to run QA tests.
75
76	The workflow is very simple, and is intended to be quite lightweight:
77	an enhancement to Debian is suggested, discussed, implemented, and
78	becomes accepted practice (or policy, if applicable), in the normal
79	Debian way. As the discussion progresses, the enhancement is assigned
80	certain states, as explained below. During all the process, a single URL
81	maintained by the proposers can be used to check the status of the
82	proposal.
83
84	The result of all this is:
85
86	1. an implementation of the enhancement and
87	2. a document that can be referred to later on without having to dig
88	up and read through large discussions.
89
90	The actual discussions should happen in the usual forum or forums for
91	the topic of the DEP. This way, DEPs do not act as yet another forum to
92	be followed. For example, a DEP suggesting changes to www.debian.org
93	graphical design should happen on debian-www, as usual.
94
95	In the same way, DEPs do not give any extra powers or authority to
96	anyone: they rely on reaching consensus in the traditional Debian way,
97	by engaging in discussions on mailing lists, IRC, or real life meetings
98	as appropriate, and not by consulting an external body for a decision.
99	To be acceptable, this consensus includes agreement from affected
100	parties, including those who would have to implement it or accept an
101	implementation.
102
103	The person or people who do the suggestion are the "drivers" of the
104	proposal and have the responsibility of writing the initial draft, and
105	of updating it during the discussions, see below.
106
107
108	Proposal states
109	---------------
110
111	<div style="float: right; text-align: center;">
112	[[!img deps/dep0/workflow.png size="500x250" alt="DEP state diagram"]]
113	<br />
114	<span style="font-size: xx-small">DEP workflow: state diagram</span>
115	</div>
116	A given DEP can be in one of the following states:
117
118	* DRAFT
119	* CANDIDATE
120	* ACCEPTED
121	* REJECTED
122	* OBSOLETE
123
124	The ideal progression of states is DRAFT -> CANDIDATE -> ACCEPTED, but
125	reality requires a couple of other states and transitions as well.
126
127	### DRAFT state: discussion
128
129	* every new proposal starts as a DRAFT
130	* anyone can propose a draft
131	* each draft has a number (next free one from document index)
132	* normal discussion and changes to the text happen in this state
133	* drafts should include extra criteria for success (in addition to
134	having obtained consensus, see below), that is, requirements to
135	finally become ACCEPTED
136
137	#### DRAFT -> CANDIDATE: rough consensus
138
139	In order for a DEP to become CANDIDATE, the following condition should
140	be met:
141
142	* consensus exists for what should be done, and how it should be
143	done (agreement needs to be expressed by all affected parties, not
144	just the drivers; silence is not agreement, but unanimity is not
145	required, either)
146
147	### CANDIDATE: implementation + testing
148
149	The CANDIDATE state is meant to prove, via a suitable implementation
150	and its testing, that a given DEP is feasible.
151
152	* of course, implementation can start in earlier states
153	* changes to the text can happen also in this period, primarily based
154	on feedback from implementation
155	* this period must be long enough that there is consensus that the
156	enhancement works (on the basis of implementation evaluation)
157	* since DEP are not necessarily technical, "implementation" does not
158	necessarily mean coding
159
160	#### CANDIDATE -> ACCEPTED: working implementation
161
162	In order for a DEP to become ACCEPTED, the following condition should
163	be met:
164
165	* consensus exists that the implementation has been a success
166
167	### ACCEPTED: have fun
168
169	Once accepted:
170
171	* the final version of the DEP text is archived on
172	<http://dep.debian.net> for future reference
173	* if applicable, the proposed DEP change is integrated into
174	authoritative texts such as policy, developer's reference, etc.
175
176	#### {DRAFT, CANDIDATE} -> REJECTED
177
178	A DEP can become REJECTED in the following cases:
179
180	* the drivers are no longer interested in pursuing the DEP and
181	explicitly acknowledge so
182	* there are no modifications to a DEP in DRAFT state for 6 months or
183	more
184	* there is no consensus either on the draft text or on the fact that
185	the implementation is working satisfactorily
186
187	#### ACCEPTED -> OBSOLETE: no longer relevant
188
189	A DEP can become OBSOLETE when it is no longer relevant, for example:
190
191	* a new DEP gets accepted overriding previous DEPs (in that case the
192	new DEP should refer to the one it OBSOLETE-s)
193	* the object of the enhancement is no longer in use
194
195	### {REJECTED, OBSOLETE}
196
197	In one of these states, no further actions are needed.
198
199	It is recommended that DEPs in one of these states carry a reason
200	describing why they have moved to such a state.
201
202
203	What the drivers should do
204	--------------------------
205
206	The only additional burden of the DEP process falls on the shoulders of its
207	drivers. They have to take care of all the practical work of writing
208	and maintaining the text, so that everyone else can just continue
209	discussing things as before. Driver's burden can be summarized as:
210
211	* Write the draft text and update it during discussion.
212	* Determine when (rough) consensus in discussion has been reached.
213	* Implement, or find volunteers to implement.
214	* Determine when consensus of implementation success has been reached,
215	when the testing of the available implementation has been satisfactory.
216	* Update the DEP with progress updates at suitable intervals, until the
217	DEP has been accepted (or rejected).
218
219	If the drivers go missing in action, other people may step in and
220	courteously take over the driving position.
221
222	Note: the drivers can of course participate in the discussion as
223	everybody else, but have no special authority to impose their ideas to
224	others. <q>DEP gives pencils, not hammers.</q>
225
226
227	Format and content
228	------------------
229
230	A DEP is basically a free-form plain text file, except that it must
231	start with a paragraph of the following RFC822-style headers:
232
233	* Title: the full title of the document
234	* DEP: the number for this DEP
235	* State: the current state of this revision
236	* Date: the date of this revision
237	* Drivers: a list of drivers (names and e-mail addresses), in RFC822
238	syntax for the To: header
239	* URL: during DRAFT state, a link to the canonical place of the draft
240	(typically probably http://wiki.debian.org/DEP/DEPxxx or
241	http://dep.debian.net/deps/depXXX)
242	* Source: one or more URLs to browse the sources used to produce the displayed
243	version of the DEP.
244	* Abstract: a short paragraph (formatted as the long Description in
245	debian/control)
246
247	(Additionally, REJECTED DEPs can carry a "Reason:" field describing
248	why they were rejected.)
249
250	The rest of the file is free form. If the DEP is kept in a wiki, using
251	its markup syntax is, of course, a good idea.
252
253	Suggested document contents:
254
255	* An introduction, giving an overview of the situation and the motivation
256	for the DEP.
257	* A plan for implementation, especially indicating what parts of Debian need
258	to be changed, and preferably indicating who will do the work.
259	* Preferably a list of criteria to judge whether the implementation has been
260	a success.
261	* Links to mailing list threads, perhaps highlighting particularly important
262	messages. If discussion happens on IRC, pointers to logs would be nice.
263
264
265	License
266	-------
267
268	The DEP must have a license that is DFSG free. You may choose the
269	license freely, but the "Expat" license is recommended. The
270	official URL for it is <http://www.jclark.com/xml/copying.txt> and
271	the license text is:
272
273	Copyright (c) <year> <your names>
274
275	Permission is hereby granted, free of charge, to any person obtaining
276	a copy of this software and associated documentation files (the
277	"Software"), to deal in the Software without restriction, including
278	without limitation the rights to use, copy, modify, merge, publish,
279	distribute, sublicense, and/or sell copies of the Software, and to
280	permit persons to whom the Software is furnished to do so, subject to
281	the following conditions:
282
283	The above copyright notice and this permission notice shall be included
284	in all copies or substantial portions of the Software.
285
286	THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
287	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
288	MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
289	IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
290	CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
291	TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
292	SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
293
294	The justification for this recommendation is that this license is one
295	of the most permissive of the well-known licenses. By using this
296	license, it is easy to copy parts of the DEP to other places, such as
297	documentation for Debian development or embedded in individual
298	packages.
299
300
301
302	Creating a DEP
303	--------------
304
305	The procedure to create a DEP is simple: send an e-mail to
306	`debian-project@lists.debian.org`, stating that you're taking the next
307	available number, and including the first paragraph of the DEP as
308	explained above. It is very important to include the list of drivers,
309	and the URL where the draft will be kept up to date. The next available
310	DEP number can be obtained by consulting <http://dep.debian.net>.
311
312	It is also a very good idea to mention in this mail the place where the
313	discussion is going to take place, with a pointer to the thread in the
314	mailing list archives if it has already started.
315
316	Additionally, drivers are welcome to maintain their DEPs, even in the
317	draft state, in a repository inside the `dep` Alioth project, following
318	the instructions at <http://dep.debian.net/depdn-howto>. They are free not to
319	do so, and in that case a DEP0 driver or some interested party will
320	update the `dep.debian.net` index with their DEP, and a pointer to the
321	URL they provided.
322
323
324	Revising an accepted DEP
325	------------------------
326
327	If the feature, or whatever, of the DEP needs further changing later,
328	the process can start over with the accepted version of the DEP document
329	as the initial draft. The new draft will get a new DEP number. Once the
330	new DEP is accepted, the old one should move to OBSOLETE state.
331
332
333
334	License
335	-------
336
337	The following copyright statement and license apply to DEP0 (this
338	document).
339
340	Copyright (c) 2008-2009 Stefano Zacchiroli, Adeodato Simó, Lars Wirzenius
341
342	Permission is hereby granted, free of charge, to any person obtaining
343	a copy of this software and associated documentation files (the
344	"Software"), to deal in the Software without restriction, including
345	without limitation the rights to use, copy, modify, merge, publish,
346	distribute, sublicense, and/or sell copies of the Software, and to
347	permit persons to whom the Software is furnished to do so, subject to
348	the following conditions:
349
350	The above copyright notice and this permission notice shall be included
351	in all copies or substantial portions of the Software.
352
353	THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
354	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
355	MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
356	IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
357	CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
358	TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
359	SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
360
361	Changes
362	-------
363
364	* 2012-03-25:
365	[ Charles Plessy ]
366	* Added a "Source" field, to transfer the VCS information from the index to
367	the DEP itself.
368
369	* 2009-07-26:
370	[ Zack, Dato, Lars]
371	* Re-word state description: describe separately states and
372	transitions.
373	* Rename "DROPPED" status to "REJECTED"; inhibit "resurrection" of
374	REJECTED DEPs.
375	* Mention that dep.debian.net is the central archival place
376	* Stress that DEPs give no special powers to drivers, in the "driver
377	role" section
378	* Change the state of DEP0 to CANDIDATE
379
380	* 2008-06-12:
381	[ Lars Wirzenius ]
382	* Added a recommendation for the Expat license for new DEPs.
383	* Set this DEP to be licensed under the Expat license.
384
385	* 2008-05-29:
386	[ Lars Wirzenius ]
387	* Added section saying that a DEP should have a DFSG free license.
388
389	* 2008-01-15:
390	[ Adeodato Simó ]
391	* Add section about how to create a DEP.
392	* Rewrite "Introduction" (splitting "Motivation" off), and parts of
393	"Workflow" as well.
394
395	[ Lars Wirzenius ]
396	* Typo fixes.
397
398	* 2008-01-11: Minor tweaks by Zack (mostly cosmetic, but also
399	some more detailed specification of former more vague aspects)
400
401	* 2008-01-09: Various cleanups and tweaks by Lars, based on feedback
402	from several parties.
403
404	* 2007-12-01: Initial version written after some quick brainstorming at
405	the QA meeting in Extremadura, Spain, by Stefano, Adeodato, and Lars.
406