web/deps/dep0.mdwn

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

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

The proposal goes through several states over its lifetime. The ideal
progression is DRAFT -> CANDIDATE -> ACCEPTED, but reality requires a
couple of other states as well.

#### DRAFT: discussion until (rough) consensus

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

#### CANDIDATE: implementation + testing

  * 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
  * implementation can of course start earlier
  * changes in this period are primarily based on feedback from implementation
  * this period must be long enough that there is a consensus that the
    enhancement works (on the basis of implementation evaluation)

#### ACCEPTED: integrate to policy/devref/elsewhere (if applicable)

  * consensus exists that the implementation has been a success
  * also, the final version of the document is archived in a central place
    (vcs on alioth, plus web page generated from that), even if integrated
    to other documents as well

#### DROPPED: no further action needed

  * the drivers are no longer interested in pursuing the DEP
  * if there are no modifications to a DEP in DRAFT state for six months,
    or there is a consensus that the implementation of a DEP in
    CANDIDATE state has been abandoned, the DEP is moved to DROPPED
    state (from which it can be resurrected by moving to DRAFT stage
    again)

#### OBSOLETE: no longer relevant

  * for example, when a new revision (as a new DEP) gets accepted, the
    old one will move to OBSOLETE state, and will be modified to refer
    to the new one


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.
* Mention somewhere explicitly that the location of the index is
  <http://dep.debian.net>.


Changes
-------

* 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	adeodato	22	Date: 2008-05-29
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			Workflow for managing discussions about improvements to Debian and
14			archiving their outcomes.
15
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			The proposal goes through several states over its lifetime. The ideal
111			progression is DRAFT -> CANDIDATE -> ACCEPTED, but reality requires a
112			couple of other states as well.
113
114			#### DRAFT: discussion until (rough) consensus
115
116			* every new proposal starts as a DRAFT
117			* anyone can propose a draft
118			* each draft has a number (next free one from document index)
119			* normal changes happen in this period
120			* drafts should include extra criteria for success (in addition to
121			having obtained rough consensus, see below), that is, for moving to
122			the ACCEPTED state
123
124			#### CANDIDATE: implementation + testing
125
126			* consensus exists for what should be done, and how it should be done
127			* agreement needs to be expressed by all affected parties, not just the
128			drivers; silence is not agreement, but unanimity is not required, either
129			* implementation can of course start earlier
130			* changes in this period are primarily based on feedback from implementation
131			* this period must be long enough that there is a consensus that the
132			enhancement works (on the basis of implementation evaluation)
133
134			#### ACCEPTED: integrate to policy/devref/elsewhere (if applicable)
135
136			* consensus exists that the implementation has been a success
137			* also, the final version of the document is archived in a central place
138			(vcs on alioth, plus web page generated from that), even if integrated
139			to other documents as well
140
141			#### DROPPED: no further action needed
142
143			* the drivers are no longer interested in pursuing the DEP
144			* if there are no modifications to a DEP in DRAFT state for six months,
145			or there is a consensus that the implementation of a DEP in
146			CANDIDATE state has been abandoned, the DEP is moved to DROPPED
147			state (from which it can be resurrected by moving to DRAFT stage
148			again)
149
150			#### OBSOLETE: no longer relevant
151
152			* for example, when a new revision (as a new DEP) gets accepted, the
153			old one will move to OBSOLETE state, and will be modified to refer
154			to the new one
155
156
157			What the drivers should do
158			--------------------------
159
160			The additional, hopefully small, burden of the DEP process falls on the
161			shoulders of its drivers. They have to take care of all the practical
162			work of writing and maintaining the draft, so that everyone else can
163			just continue discussing things over e-mail as before. Driver's burden
164			can be summarized as:
165
166			* Write the draft.
167			* Update the draft during discussion.
168			* Determine when (rough) consensus in discussion has been reached.
169			* Implement, or find volunteers to implement.
170			* Determine when consensus of implementation success has been reached,
171			when the testing of the available implementation has been satisfactory.
172			* Update the DEP with progress updates at suitable intervals, until the
173			DEP has been accepted.
174
175			If the drivers go missing in action, other people may step in and
176			courteously take over the driving position.
177
178
179			Format and content
180			------------------
181
182			A DEP is basically a free-form plain text file, except that it must
183			start with a paragraph of the following RFC822-style headers:
184
185			* Title: the full title of the document
186			* DEP: the number for this DEP
187			* State: the current state of this revision
188			* Date: the date of this revision
189			* Drivers: a list of drivers (names and e-mail addresses), in RFC822
190			syntax for the To: header
191			* URL: during DRAFT state, a link to the canonical place of the draft
192			(typically probably http://wiki.debian.org/DEP/DEPxxx or
193			http://dep.debian.net/deps/depXXX)
194			* Abstract: a short paragraph (formatted as the long Description in
195			debian/control)
196
197			The rest of the file is free form. If the DEP is kept in a wiki, using
198			its markup syntax is, of course, a good idea.
199
200			Suggested document contents:
201
202			* An introduction, giving an overview of the situation and the motivation
203			for the DEP.
204			* A plan for implementation, especially indicating what parts of Debian need
205			to be changed, and preferably indicating who will do the work.
206			* Preferably a list of criteria to judge whether the implementation has been
207			a success.
208			* Links to mailing list threads, perhaps highlighting particularly important
209			messages. If discussion happens on IRC, pointers to logs would be nice.
210
211
212	adeodato	22	License
213			-------
214
215			The DEP must have a license that is DFSG free. You may choose the
216			license freely, but the "Expat" license is recommended. The
217			official URL for it is http://www.jclark.com/xml/copying.txt and
218			the license text is:
219
220			Copyright (c) <year> <your names>
221
222			Permission is hereby granted, free of charge, to any person obtaining
223			a copy of this software and associated documentation files (the
224			"Software"), to deal in the Software without restriction, including
225			without limitation the rights to use, copy, modify, merge, publish,
226			distribute, sublicense, and/or sell copies of the Software, and to
227			permit persons to whom the Software is furnished to do so, subject to
228			the following conditions:
229
230			The above copyright notice and this permission notice shall be included
231			in all copies or substantial portions of the Software.
232
233			THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
234			EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
235			MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
236			IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
237			CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
238			TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
239			SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
240
241			The justification for this recommendation is that this license is the
242			most permissive of the well-known licenses. By using this license, it is
243			easy to copy parts of the DEP to other places, such as documentation for
244			Debian development or embedded in individual packages.
245
246
247
248	adeodato	7	Creating a DEP
249			--------------
250
251			The procedure to create a DEP is simple: send an e-mail to
252			`debian-project@lists.debian.org`, stating that you're taking the next
253			available number, and including the first paragraph of the DEP as
254			explained above. It is very important to include the list of drivers,
255			and the URL where the draft will be kept up to date. The next available
256			DEP number can be obtained by consulting <http://dep.debian.net>.
257
258	adeodato	12	It is also a very good idea to mention in this mail the place where the
259			discussion is going to take place, with a pointer to the thread in the
260			mailing list archives if it has already started.
261
262	adeodato	7	Additionally, drivers are welcome to maintain their DEPs, even in the
263			draft state, in a repository inside the `dep` Alioth project, following
264			the instructions at <http://dep.debian.net/howto>. They are free not to
265			do so, and in that case a DEP0 driver or some interested party will
266			update the `dep.debian.net` index with their DEP, and a pointer to the
267			URL they provided.
268
269
270			Revising an accepted DEP
271			------------------------
272
273			If the feature, or whatever, of the DEP needs further changing later,
274			the process can start over with the accepted version of the DEP document
275			as the initial draft. The new draft will get a new DEP number. Once the
276			new DEP is accepted, the old one should move to OBSOLETE state.
277
278
279
280	adeodato	22	License
281			-------
282
283			The following copyright statement and license apply to DEP0 (this
284			document).
285
286			Copyright (c) 2008 Stefano Zacchiroli, Adeodato Simó, Lars Wirzenius
287
288			Permission is hereby granted, free of charge, to any person obtaining
289			a copy of this software and associated documentation files (the
290			"Software"), to deal in the Software without restriction, including
291			without limitation the rights to use, copy, modify, merge, publish,
292			distribute, sublicense, and/or sell copies of the Software, and to
293			permit persons to whom the Software is furnished to do so, subject to
294			the following conditions:
295
296			The above copyright notice and this permission notice shall be included
297			in all copies or substantial portions of the Software.
298
299			THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
300			EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
301			MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
302			IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
303			CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
304			TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
305			SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
306
307
308
309
310	adeodato	7	TODO
311			----
312
313			* Figure out how to mark up a DEP file in wiki.debian.org's syntax
314			in such a way as to make the initial RFC822-style paragraph format
315			sensibly, but without making it require much or any wiki markup.
316			* Mention somewhere explicitly that the location of the index is
317			<http://dep.debian.net>.
318
319
320			Changes
321			-------
322
323	adeodato	22	* 2008-06-12:
324			[ Lars Wirzenius ]
325			* Added a recommendation for the Expat license for new DEPs.
326			* Set this DEP to be licensed under the Expat license.
327
328			* 2008-05-29:
329			[ Lars Wirzenius ]
330			* Added section saying that a DEP should have a DFSG free license.
331
332	adeodato	7	* 2008-01-15:
333			[ Adeodato Simó ]
334			* Add section about how to create a DEP.
335	adeodato	8	* Rewrite "Introduction" (splitting "Motivation" off), and parts of
336			"Workflow" as well.
337	adeodato	7
338			[ Lars Wirzenius ]
339			* Typo fixes.
340
341			* 2008-01-11: Minor tweaks by Zack (mostly cosmetic, but also
342			some more detailed specification of former more vague aspects)
343
344			* 2008-01-09: Various cleanups and tweaks by Lars, based on feedback
345			from several parties.
346
347			* 2007-12-01: Initial version written after some quick brainstorming at
348			the QA meeting in Extremadura, Spain, by Stefano, Adeodato, and Lars.
349