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

Re: RFC: Introducing Debian Enhancement Proposals (DEPs)

On Thu, Jan 17, 2008 at 09:18:22AM +0100, Stefano Zacchiroli wrote:
> In the current proposal d-project is only used as a global mutual
> exclusion tool to get the next available number in the DEP namespace, no
> other announcement purpose is intended for d-project.
> The underlying overall idea is that the DEP process should not change
> the way in which the discussions are carried on in Debian, but just give
> a tool to keep track of what is happening / has happened. So, the
> announcement device to be used is the one that the driver would have
> used if the DEP process did not exist at all. The less constraints added
> by DEPs, the better :-)

I think using the list only as a mutual exclusion tool is good, for the
reasons you mention.  However, for the mutual exclusion to work
smoothly, it would probably be better to mail through a proxy, as Sven
proposed.  I'm thinking of sending a mail there with the DEP header, but
with the version set to an invalid value (TO-BE-ASSIGNED for example).
Then the proxy will insert its next number in there and send the result
to the list, and to the submitter (the submitter will get it twice, but
the direct reply may be much faster, which is good for the "I want to do
everything right now" sort of people).  If the mail isn't a proper DEP
header, it should probably bounce (or be ignored if too much traffic is
generated, to avoid it being used for spam).

If people like the idea, I can write something to do this.

With the requirement that DEPs mention where the discussion will take
place, this can be the only mail about that DEP going to -project.

> If people find that such a bootstrap announcement is needed we can go
> for it, but given that an automatic publishing system would exists for
> the DEP, we can even subscribe d-d-a to a RSS feed of the DEP page or
> something like that, but maybe is too early for this.

Subscribing d-d-a to anything sounds like a very bad idea to me...

About my idea of splitting ACCEPTED into historical and current, this
may actually be what OBSOLETE was meant for.  I thought OBSOLETE was
only to be used for DEPs which have a new version after they got
ACCEPTED.  However, if OBSOLETE is also used for DEPS which are
implemented in policy, for example, then there is no reason to split the
ACCEPTED DEPs, I think.  The "current" ones are then simply all ACCEPTED


I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

Attachment: signature.asc
Description: Digital signature

Reply to: