|
Andrew John Hughes wrote: Could you provide a link for that? I wasn't aware of that.(snip) and anything non-trivial has to be approved formally, again in public. If you have a formal process which is enforced, then how can it become "lax"? At every projectThings probably have become a little lax of late, I'll admit, I've been on, almost every developer would like to bypass the process on occassion. If there's no process to stop that, then it's not much of a process. It's actually Classpath mailing list archives that makes me feel like there's not enough process,Look on the Classpath mailing list archives and you will see evidence of all this. and I don't mean just over the last year or so. I would have expected far more substance - like 10x or 100x. Not just quantity but the content, too. One example: a while ago, the issue of how closely toString() methods should match whatever the JDK version produces. There was a little discussion followed by a lead person summing it up as "each developer should just do the best he can". That could have been handled very differently, with huge amounts of discussion, escalation, surveys of users, reviews of the project's stated goals, and maybe even a completely different "all toString() method need to match the JDK exactly, and all developers must spend whatever time it takes to do it" outcome under closed source. I'm not saying one approach is necessarily better than the other. So when you say Classpath has a "clear and open development process which allows anyone to join in", that sounds good, but may not be better than the alternative. In the example above, a top-down "you will be 100% compatible" edict could actually work well to help compatibility. I consider Sun's bug database "public", but OK.Quality control is not part of the administrative issues I was referring to. What I was referring to is the existence of a public bug database, public patch discussion and a general open and community-oriented process which are in the pipelines but don't yet exist. These are mainly social issues, not technical. It will take time for Sun engineers to adjust to growing and working with a FOSS community around the OpenJDK. The codebase may be mature and stable, the community is still nascent. Hmmm. Yes, closed source developers do have as much fun as open-source, at least in my experience.And 'fun' is a very subjective term; I mean it in a very social sense, of people working together and camaraderie -- no doubt the engineers in Sun had equally as much fun creating the JDK as we have with GNU Classpath. My point was more that, so far, there is still a line between 'them' and 'us'. We haven't been invited to the OpenJDK party inside Sun yet, so our only fun remains in the GNU Classpath project . As for "being invited", I'm not sure what you're waiting for specifically, and maybe Sun doesn't either. And whether or not you're invited, you can participate in OpenJDK any time you like. The bug database is indeed public, the code is GPLv2, Sun employees are happy to have email patch discussions, which you can make public if you like. I'm not sure what else you're looking for when you say "a general open and community-oriented process which are in the pipelines but don't yet exist", but if it's something like "just give me checking permissions and release builds much more often", I wouldn't hold my breath. Right, so if the quality control is getting in the way of "fun", that's not going to change.Of course it wasn't a jab at Sun, I wouldn't be able to work on this to start with if it wasn't for the hard work that's gone into the OpenJDK release. But I'm not going to lie and say everything in the garden is rosy either. I don't think you can generalise to all FOSS projects; there are clearly different levels of quality control required depending on the stability of a project. If a project is just starting either from scratch or on a major new release, you'd expect to see a rash of development as new ideas are experimented with, etc. In contrast, you'd expect to see minor changes and bug fixes to something pretty feature-stable (I guess something like the coreutils which provide ls and friends). GCC, for example, spends more time in regression and bug-fixing mode than in feature addition. I guess the fact that you're going to try to patch Classpath is proof of that. It's your choice, of course, but it's a shame to waste your time on that, IMO. Seems like every time a FOSS developer points out a difference between open and closed source,You mention the concept of a release several times. One of the main differences between FOSS and proprietary development is that you only ever see the release in a proprietary project. my response is "no, closed source is not that way at all". Why do you say that you only see the release in the proprietary project? You can see every build of JDK6, for example. The fact that OpenJDK is available under a different license doesn't change that. Either way, you can see every change made by everyone. Sure, you don't see every email exchanged between Sun developers, but then again, I can't see every email between Classpath developers either. I agree Sun should open things up a lot more, I'm just saying that "you only see the release" doesn't apply to Java. I'm a lot more comfortable knowing there's a large Quality group at Sun, and having to waitSo you can't see what went on beforehand or whether these processes were always adhered to (I'm not saying that's not the case, just that it's possible). weeks or months for a release, then I am about being able to download a release that could have been checked in an hour ago. I'm also a lot more confident in Sun's TCK than in Classpath's Mauve test suite. I'm also more confident when, presumably, a Sun employee knows he'd be fired for checking in a change introduced a nasty bug, which he never tested and never had reviewed. The worst that would happen to a Classpath developer who did the same thing is that his commit rights would be taken away. Not much of a disincentive. Yes, obviously my mileage varies. gjc crashed on my the first time I tried it, for example, whileYou may have all the right ingredients, but it doesn't mean you're always going to get a perfect product out the oven at the end. My general experience has been that I run into far more bugs with proprietary products, which then doubly annoys me because I can't do much about it because of the arbitrary separation between user and developer. Your mileage may vary of course, but proprietary development by no means produces perfect products. You just see less of the debris as the work is being done. javac hasn't crash on me in years. Last time I tried Classpath, it turned out the feature I tried (JTable) was listed as completed, but all the methods did nothing yet. I have little problem with various Linux distros and cygwin and mozilla, but I have little problem with UN*X distros, MKS toolkit, and IE either. I don't think the separation between user and developer is arbitrary at all. The Hotspot developers are one group, Java application developers are another, and end users are a third. People like you can indeed be all three, but (and rms) you're pretty rare. Yes, I don't want to discourage you or anyone else from saying anything anything. I just want to chime in and question your assumptions about the best way to do things, especially if I think they involve assumptions about closed source that I don't think are true. OK, and feel free to let me know which things you think I don't know much about. Otherwise, it comes across as a baseless personal attack.
|
