date parser

Before talking about why I vetoed putting the date parser into the 1.0
stabilization branch, I figured it would be best to review what a veto
means. Some people here will certainly be familiar with this, but I'm not
sure that's the case for everyone. The biggest thing, I think, is that a
veto doesn't have to be a big deal. In essence, it is merely a brake on
coding, pending discussion. So...

By definition, a veto only applies to code changes (rather than, say,
process discussions or release decisions). The veto must be accompanies by
a technical reason. There is some grey area on what "technical" can mean,
but the vetoer receives the benefit of the doubt. Along with the reason,
there must also be a willingness and an effort to work with the coder and
the community to work through the issues that are behind the reason for
the veto. IOW, unjustified or drive-by vetoes are not allowed; there must
be something that people can focus on and work together to solve. The
intent is always to remove the veto.

Vetoes can be applied before or after code is committed. There is also no
concept of a "statute of limitations." A commit from a year ago could be
vetoed as a bad idea for whatever reason (iow, just cuz it has been there
doesn't make it any less of a bad idea :-). If the veto arrives before the
code is committed, then it simply becomes a discussion before a commit can
occur. If the commit has already occurred, then the discussion also takes
place, but a release cannot be made which incorporates the code, unless or
until the veto is lifted or the commit is reverted.

Back to the matter at hand...

I'm only -0 on the concept of a date parser rewrite. If we were at another
time in our "release curve", then it would be no big deal. However, that
isn't the case here, so this kind of rewrite introduces a measure of risk
into the release. Today, getdate.y has not changed since we imported it
into the repository back in August, 2001; no idea about its history within
the old CVS repos. During that whole time, I don't recall any "big"
problems that people have actually experienced. It seems the largest issue
is missing the ISO formats, rather than a defect, per se. Against that
stability, we're talking about introducing new, untried code with some
number of potential issues.

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.

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.

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.

I worry that even if each of these things were addressed, then at that
point, we'll be even further down the road where the risk/benefit tradeoff
is even more weighed against changes.

I believe the proper resolution is to recognize that the date formats are
just another "contract" (to borrow ghudson's terms w.r.t APIs). SVN will
make certain guarantees about specific forms of input. Pass something else
at your own risk. If you depend upon behavior outside of the contract,
then too bad if we need to alter code. We do this in many areas of the
code. Where we find implicit contracts, then we try to document those to
make them explicit. I'd like to posit that we're in the exact same
situation here. Our cmdline client has got a lot of implicit behaviors
that we try to document, and I believe that the acceptable formats are
simply one of those situations.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org