001-process.txt thoughts

[Nick Mathewson]

On Mon, Feb 19, 2007 at 09:41:35PM -0500, phobos at rootme.org 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070219/7a29b41a/attachment.pgp>