> Tom Lord wrote:
>> Do you think that such sabotage is what's going on here?

Anton van Straaten wrote:
> I have no way to know, and that wasn't my point.  My inclination is to
> give people the benefit of the doubt, on both sides.  My point is that
> even if that's not what's happening here, a hasty withdrawal under
> pressure now would provide a clear strategy for such attempts in
> future ....

Meanwhile, I feel that the author is trying to pressure reviewers with
a looming deadline for finalization, using it (among other things) to
brush off advice from experts in their fields. I don't think that's
right either.

I'm not trying to *pressure* the author into withdrawing his proposal.
At first, I was even trying to honor the deadline pressure and keep
changes to a minimum. However, I eventually realized that the remaining
issues are too complicated to resolve with simple tweaks, and that the
discussion & revisions could keep going on much longer. At that point, I
strongly recommended withdrawal to resolve the issues without the
pressure of that self-imposed deadline.

> Of course, it could be argued the other way that allowing the draft
> period to be greatly extended is also a poor precedent for the SRFI
> process. That's probably true.  However, this SRFI was already way
> over the alloted draft period.  I don't know the history of that - if
> there's a procedural problem, it should have been addressed a long
> time ago.  But it doesn't make much sense to me to suddenly start
> calling for withdrawal ....

In business, that's called "throwing good money after bad." In
parenting, it's called "two wrongs don't make a right."

> Continued calls for withdrawal, even with the goal of subsequent
> resubmission, unnecessarily complicate the discussion.

We are calling for withdrawal partly because we're still finding
defects, and the resolution doesn't look like it'll be quick, despite
the author's optimistic assurances. We are also calling for withdrawal
because the SRFI fails to meet some basic requirements of the SRFI
process at this late date, and at least one defect was found late
precisely because the SRFI didn't follow the guidelines!

Meanwhile, the author is claiming that it's OK for him to ignore the
process, because he allegedly understands what it's really all about.
Well, if the SRFI process is really all about ignoring the basic
requirements (and letting defects slip in because of that!), then what
good is the process?

> Much has been made of the rules of the SRFI process, but as open as it
> is, I think it depends on the exercise of a certain amount of good
> will on all sides.  Blindly insisting on imposing rules which have
> already been stretched doesn't seem to qualify, to me.

Nor does insisting that the rules don't apply to you, and *continuing*
to insist that even after we've found a bug that resulted from it! The
author is acting as though the SRFI process is his own private
plaything, and the editors are just letting it slide.

I have not been *blindly* insisting on the rules. The process clearly
aims to discourage immature implementations. (Or at least that's what
the written process says.) This implementation is clearly immature! It
isn't stable, it isn't well-tested, it isn't even fully implemented.
The author keeps denying that, claiming that I'm making a "subjective"
judgment. Now you're claiming that it's "blindly following rules."

Please, offer *any* definition of "mature" that this "implementation"
fits. Please explain why we should hash out design issues in a forum
that is explicitly *not* for preliminary ideas.

I realize that you're trying to be tactful and diplomatic and offer a
compromise here, but it won't help, because your compromise just
undermines the process even more.
--
Bradd W. Szonye
http://www.szonye.com/bradd