>>>>> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath