On 09:20 Wed 08 Dec , Pekka Enberg wrote: > On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes > > > > There are several inaccuracies in the points themselves. I'm not too > > surprised, given that Pekka is still new to the project, but I am surprised > > that you'd agree wholeheartedly with such little hesitation. > > I hope my inaccuracies didn't get into the way of the overall point. > No, and as I said, they were understandable from someone new to the project. > On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes > <gnu_andrew@xxxxxxxxxxxxxx> wrote: > > 1.6 work has already been done on GNU Classpath, though that is now > > some time back; it's all there in the mailing list archives though. > > Last time I tested Jato with GNU Classpath, there were some obvious > missing 1.6 APIs in java.lang.Math, for example. I need to check if > that's changed now. The overall feel I get from GNU Classpath is that > it's quite firmly stuck at 1.5 level, though. > I wasn't saying it was by any means complete, just that there was already some progress in that area and we hadn't decided to do 1.5 only. For example, I updated most of the JMX implementation to the 1.6 level. Live comparisons are here: http://builder.classpath.org/japi/ I don't think the OpenJDK snapshots used have been updated in a while, so the comparison for 7 will be quite dated. > On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes > <gnu_andrew@xxxxxxxxxxxxxx> wrote: > > There is no 1.7 API to implement yet, so that's a pointless statement. > > I also tend to still believe in the general Classpath spirit that we > > implement primarily to match the requirements of applications, not > > specific applications. We have no hope of ever TCKing the thing > > anyway, and to my knowledge it's never been used with a JDK that's not > > Oracle-based so I have no trust in its reliability. > > There's APIs that are likely to make it into 1.7 (e.g. NIO2). I don't > see much to be gained from not implementing them now. You might have a > different view on what should be implemented and what not but that > doesn't make my statement pointless. Ok, maybe not pointless, but hardly 'critical' as you claimed in your blog. Applications aren't going to be relying on 1.7 code just yet. I've only recently started to see 1.6 dependencies (and mainly in OpenJDK). > > >> Now the cool thing would be if I said "lets do them all right now!". > >> But instead I am going on vacation and be offline for about two weeks. > >> Sorry about that. But I didn't want to not respond at all. > >> > >> As soon as I am back I would like us to at least start moving to > >> mercurial on savannah if people don't mind. > > > > Yes, I do mind. > > > > We already discussed this some time back: > > > > http://developer.classpath.org/pipermail/classpath/2008-June/002629.html > > > > and nothing happened. I don't particularly see any huge benefit to > > moving the repository to a different version control system. It would > > make more sense if there were lots of contributors but there aren't. > > As is, if you're going to put some time in, I'd rather it was spent > > reviewing patches than messing about with the VCS. > > Hey, it's not as if I'm making this up! This is a genuine experience > from someone who wanted to contribute a simple thing to GNU Classpath. > While *you* don't see the benefit from transitioning to Mercurial or > git, I certainly do, and I claim other people who are used to modern > tooling see that as well. I didn't say there wasn't a benefit, I said there wasn't a 'huge benefit'. If you read the link I posted, you will see it was me who proposed a shift to Mercurial over two years ago, so I clearly think it is beneficial. I agree CVS isn't ideal by a long shot. However, in the general scheme of things, I don't think it's as important as getting patches reviewed. Moving to Mercurial is not going to make all the patches get reviewed and committed. The real advantages of DVCS show up when you have lots of active developers, and are especially useful in remote situations as they allow you to commit without having to push at the same time. But not having Mercurial hardly stops people writing patches. > > On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes > <gnu_andrew@xxxxxxxxxxxxxx> wrote: > > One of Pekka's motivations is also flawed: > > > > 'how much problems it causes for developers that don't have commit > > rights to the centralized repository!' > > > > Moving it all to Mercurial just so it's easier for someone else to > > create a forked lower-quality copy that accepts unreviewed patches is > > not a good motivation IMHO. > > I hope you don't mean this: > > https://github.com/penberg/classpath > > because it's (a) not a fork (it's queue of patches I want to feed to > mainline) and (b) I don't merge unreviewed patches (I reviewed them > myself). > No, I didn't mean that specifically, but your blog gave the impression that an advantage to Mercurial was that you could avoid the main repository. Sure, you can commit locally in Mercurial where you can't in CVS, but main repository access is still needed for the patches to enter the main development stream. snip.. > P.S. I hope my blog post didn't come across as negative towards GNU > Classpath maintainers. I much appreciate the work you're doing and > just wanted to share my thoughts on what _I_ think needs to change for > people like me to be able to contribute to it. > Thanks. I think your comments are helpful and I appreciate them. > Pekka > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
