[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Introducing Debian Enhancement Proposals (DEPs)

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?


Attachment: signature.asc
Description: Digital signature

Reply to: