On Wed, 2004-01-07 at 06:38, Greg Stein wrote:
> By definition, a veto only applies to code changes (rather than, say,
> process discussions or release decisions).
Except in this case, the STATUS file says "A change needs three +1
votes... and no vetoes, to go into the release." So the meaning of this
particular veto is rather different from what you described.
> The current patch still seems to have a few open issues on the recognized
> formats (e.g. cvs/rcs formats, or use of a slash). At this point in the
> release, I'd hope we would have a more solid closure/consensus on the
> formats before application.
This is FUD. We know we can add formats more easily than we can take
them away, so mbk chose to start conservatively. Given that, it's
positively expected that someone will identify a candidate to be added.
That doesn't translate into an "open issue" with the patch.
> My second issue is that the patch is incomplete. I recognize that is
> simply because it is meant as a "talking reference", but that is too loose
> for application to the 1.0 branch. The Windows build still makes reference
> to getdate.*, and there aren't any regression tests around this
> functionality to give some confidence that we aren't introducing bugs.
I don't think the patch was meant as a "talking reference." This is the
first indication I've seen that the patch is incomplete.
The Windows build is a good point. I'll see what I can do about fixing
that. The lack of regression tests does not seem like it should be
considered a show-stopper, since we have no such tests around getdate.y.
("But we have three years of experience around getdate.y" is an obvious
answer, but it lacks perspective. People don't use dates much, so we're
unlikely to have found out if people encountered weird corner-case
behavior with getdate.y.)
> The final point kind of balances itself out: this code doesn't get used or
> exercised that much, so there isn't a lot of need to "fix" it. But by the
> same token, that also means that introducing problems here will have a
> very low impact.
Regardless of how important a piece of code is, we should try to ensure
that it is correct and maintainable--if not now, then eventually. I am
adamant about fixing the date parser before 1.0 (now that mbk has
provided an avenue to do so) because if we don't fix it now, we have no
sane road map towards making it correct or maintainable later. (As I
noted before, I don't consider your road map sane, even a little bit.)
(How is getdate.y incorrect? It's not thread-safe. It recognizes many
things it shouldn't, and doesn't recognize some things it should. It
parses MM/DD/YY[YY] in a US-locale-centric manner. Just for starters.)
Karl wrote:
> It would be painful to discover a subtle date parsing bug right after
> releasing 1.0.
No, not really. An obscure date-parsing bug seems like the epitome of
painlessness, as far as bugs go. We'd fix it in 1.0.1 and that would be
that.
(Also, we're parsing a handful of date formats here, not C code. There
just aren't all that many corner cases.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 7 18:55:59 2004