Implementing java.text
Hi Michael, hi Guilhem, while trying to merge in the latest improvements in Classpath, I noticed that Michael started reformatting java.text, and fixing some problems on his own. Which is a great thing, but leaves me with a small problem: It makes my back-merging work harder, as kaffe already uses the patches submitted by Guilhem to the Classpath bug tracker. See http://savannah.gnu.org/bugs/?group=classpath for an overview. I'd like to suggest reviewing those patches, and then deciding on merging them in or whether another implementation of those aspects of java.text is necessary. If there is anything I can personally do to make sure the contributions from kaffe developers make their way back into Classpath, I'd appreciate hearing about it. I guess we should just talk to each other more often ;) cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Implementing java.text
Dalibor Topic wrote: > Hi Michael, hi Guilhem, Hi Dalibor, (always here but a lot busy ;) ) > > while trying to merge in the latest improvements in Classpath, I noticed that Michael started reformatting java.text, and fixing some problems on his own. Which is a great thing, but leaves me with a small problem: > > It makes my back-merging work harder, as kaffe already uses the patches submitted by Guilhem to the Classpath bug tracker. See http://savannah.gnu.org/bugs/?group=classpath for an overview. I'd like to suggest reviewing those patches, and then deciding on merging them in or whether another implementation of those aspects of java.text is necessary. Yes, it's a problem I fear for some time now. I also noticed that some changes have been made to InetAddress and that I need to port these changes without compromising the already fixed bugs in kaffe (IPV6 compatibility). Hopefully, I will have some time to work on kaffe/Classpath in two weeks. > > If there is anything I can personally do to make sure the contributions from kaffe developers make their way back into Classpath, I'd appreciate hearing about it. I guess we should just talk to each other more often ;) I would also like to help. Cheers, Guilhem. > ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Implementing java.text
Guilhem Lavaux <[EMAIL PROTECTED]> writes: > If there is anything I can personally do to make sure the > contributions from kaffe developers make their way back into > Classpath, I'd appreciate hearing about it. I guess we should just > talk to each other more often ;) Other than more people with more time to spend on reviewing and commiting patches, I don't know. I find it a tad difficult to evaluate some patches without test cases. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Implementing java.text
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 18. Oktober 2003 22:24 schrieb Brian Jones: > Guilhem Lavaux <[EMAIL PROTECTED]> writes: > > If there is anything I can personally do to make sure the > > contributions from kaffe developers make their way back into > > Classpath, I'd appreciate hearing about it. I guess we should > > just talk to each other more often ;) > > Other than more people with more time to spend on reviewing and > commiting patches, I don't know. I find it a tad difficult to > evaluate some patches without test cases. My testcases are in Mauve. Michael. - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/k4wQWSOgCCdjSDsRAraAAKChbd0UKj6LRvuUquKftkXmlXJW6gCdHMrM 8Jj64HMtYEp0XJr+ktOyRVU= =wcHi -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Implementing java.text
> "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
