On Mon, Feb 19, 2007 at 09:41:35PM -0500, phobos@xxxxxxxxxx wrote: > Overall, I think 001-process.txt is acceptable. If you don't > know what I'm talking about, see > http://tor.eff.org/svn/trunk/doc/spec/proposals/001-process.txt > > There is one paragraph over which I do have a concern. > > "Like an RFC, every proposal gets a number. Unlike RFCs, proposals can > change over time and keep the same number. The history for each > proposal will be stored in the Tor Subversion repository." > > My concern is that versions of a proposal will change over time, > but not the proposal number. The proposal numbers will need to > be referred to in the view of svn revisions to determine which > version of a proposal is up for discussion. Say we implement > UDP over Tor. As the proposal matures, it may be substantially > different than originally intended. Or, after it is > implemented, we want to update it to UDPv2 or something. I > understand, perhaps mistakenly, the current proposal process > would allow the author of the proposal to simply commit a new > version of the UDP over Tor spec as the same proposal number. Hi, Phobos! I'm basing this aspect of the proposals idea on the Python Enhancement Process, which seems to work pretty well for them. Generally, preventing proposals from changing completely is a matter for the PEP editor to enforce, and what constitutes a "complete change" is as a matter of taste. For Tor, I think we should do more or less the same thing. > I'd like to see proposal numbers, once accepted, freeze. Ah, yes. The intention was that proposals freeze once they are closed or rejected. I'll change 001-process.txt to say that more clearly. > I also > propose that the spec number is the same as the proposal > number. Disagree. Proposals are supposed to get merged into the specs, so that the specs stay as an internally consistent and complete document of what Tor actually does. Take the (accepted) proposal 106, for example: it describes a change to the certificate verification rules, not a new part of the spec per se. > I'm also leery of building too onerous a process around this. Also agreed. I think we should get the approximate outlines of this figured, and then make the rest up as we go along. yrs, -- Nick Mathewson
Attachment:
pgpNXg6kklClQ.pgp
Description: PGP signature