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

Re: More on SRFI-1/SRFI-13 inconsistency in tabulate procedure

This page is part of the web mail archives of SRFI 1 from before July 7th, 2015. The new archives for SRFI 1 contain all messages, not just those from before July 7th, 2015.

Olin Shivers <shivers@xxxxxxxxxxxxxxxxxxx> writes:
> What do people think? 

Issuing a new SRFI is certainly correct wrt. modelling the process on
the RFC process. I would like to see the inconsistency fixed in the
direction of consistency with map &cet. If it takes a new SRFI, do it,
even with 'wait-a-year'.

OTOH, there's no reason why we just can't create an amendment process
for SRFIs either. It's our process and as long as it gets documented,
who cares? I would prefer to see SRFI-1 fixed w/out a new number;
tracking through the threads of obsoleted RFCs has become mighty
tedious over the years. Who would need to be convinced to make it
happen? Should this discussion (having a SRFI amendment process) go
back to c.l.s?

david rush
X-Windows: It was hard to write; it should be hard to use.
	-- Jamie Zawinski