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 ones. Thanks, Bas -- 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
signature.asc
Description: Digital signature
