On Wed, Jan 16, 2008 at 12:18:30PM +0100, Adeodato Sim?? wrote: > 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, [...] Isn't it useful to have sample implementations before trying to decide whether an idea is good or not? PEPs often seem to have patches for the feature they're suggesting, before they're accepted. > 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, [...] bugs.debian.org/ gives us a central index of ways in which Debian should be improving, along with all of: > 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. > 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. These sorts of issues are already tracked with the BTS, for instance when they're dealt with by the tech-ctte or -policy. > * 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. Is it really a good idea to merge "this is how we run our distribution" and "this is how we organise our project" ? > The result of all this is: > 1. an implementation of the enhancement and That's kind of implied by any process that results in changes happening... > 2. a document that can be referred to later on without having to dig > up and read through large discussions. What's the benefit of this, as distinct from maintained documentation that's distributed with the feature? > The actual discussions should happen in the usual forum or forums for > the topic of the DEP. [...] > In the same way, DEPs do not give any extra powers [...] > 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. In so far as a DEP is about tracking a feature request, the BTS seems the right way to handle it. > #### 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 These are all possible with the BTS right now. > #### 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 Tagging the bug "confirmed" allows this right now. > * this period must be long enough that there is a consensus that the > enhancement works (on the basis of implementation evaluation) Adding delays seems to contradict the previous notes about DEPs not changing who gets to make decisions -- if it takes five minutes for the maintainer of a package to say "omg, what a great idea", why shouldn't it be implemented immediately? > #### 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 Tag it "patch" or close the bug, and this already happens. > #### 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) Tag it "wontfix" or close the bug, and this already happens. > #### 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 Add a note to refer to the later bug, and close this report. > 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 All these are handled by the BTS (title, bug#, tags, date, owners). > * 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) You could handle this the same way, or include the latest draft inline or as an attachment. > 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. Sending a mail to submit@bugs.debian.org does this already; if the mail to -project is desired, use a pseudopackage maintained by -project. The "project" pseudopackage fits that description; there's also the "general" pseudopackage which is maintained by -devel. Is there any reason to go with all the overhead of this proposal, rather than just managing the general/project pseudopackages in the BTS along the lines suggested for DEPs -- eg, actually closing old proposals and making sure current proposals are actually going somewhere? Cheers, aj
Attachment:
signature.asc
Description: Digital signature