This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
> 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