web/deps/dep0.mdwn

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

    Title: Introducing Debian Enhancement Proposals (DEPs)
    DEP: 0
    State: DRAFT
    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
    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.

As 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
---------------

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 that the implementation of a DEP in CANDIDATE
  state 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.


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

The additional, hopefully small, 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 draft, so that everyone else can
just continue discussing things over e-mail as before.  Driver's burden
can be summarized as:

* Write the draft.
* Update the draft 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.

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


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)
* Abstract: a short paragraph (formatted as the long Description in
  debian/control)

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 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/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  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.


TODO
----

* Figure out how to mark up a DEP file in wiki.debian.org's syntax
  in such a way as to make the initial RFC822-style paragraph format
  sensibly, but without making it require much or any wiki markup.


Changes
-------

* 2009-07-26:
  [ Stefano Zacchiroli ]
  * Re-word state description: describe separately states and
    transitions.
  * Rename "DROPPED" status to "REJECTED"; inhibit "resurrection" of
    REJECTED DEPs.
  [ Stefano Zacchiroli, Lars Wirzenius ]
  * mention that dep.debian.net is the central archival place

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