Re: Implementing java.text

[Tom Tromey]

>>>>> "Dalibor" == Dalibor Topic <address@hidden> writes:

Dalibor> It makes my back-merging work harder, as kaffe already uses the
Dalibor> patches submitted by Guilhem to the Classpath bug tracker. See
Dalibor> http://savannah.gnu.org/bugs/?group=classpath for an overview. I'd
Dalibor> like to suggest reviewing those patches, and then deciding on merging
Dalibor> them in or whether another implementation of those aspects of
Dalibor> java.text is necessary.

That sounds sensible to me.

Whenever I review patches, it really helps if they follow certain
rules.  It's easiest if each logical change is a separate patch, if
the patches are uni- or context-diff (not a problem in this case, but
sometimes people post plain diffs, which are unreadable), if there is
a ChangeLog entry.  In the best case there's also a Mauve test.  If
any of these things are missing, I tend to put off review, as it means
more work for me... (e.g., sometimes I've rewritten tests into Mauve
format.  This gets old).

(I know this is nothing you don't already know, since we've discussed
it several times on irc, so I'm writing for the non-irc-using
audience... :)

Dalibor> If there is anything I can personally do to make sure the
Dalibor> contributions from kaffe developers make their way back into
Dalibor> Classpath, I'd appreciate hearing about it.

I think the best case scenario is that the kaffe developers end up
with write access to Classpath, just like developers who work on other
VMs.

I do think that at some point we should tighten Classpath commit rules
a bit.  I'm afraid this will be an unpopular move, but it does seem
important.  For instance, we could require an approval for every patch
(but still leave committing up to the author).  Or we could require a
test case for every patch (with the ability to ask for an exception,
since sometimes this isn't possible).

Tom