On Sat, Oct 19, 2002 at 11:15:38PM -0400, Michael Wiktowy wrote: > I certainly didn't interpret a week-countdown reset each time a bug is found > in Oskar's bug release pseudo-code.
You interpreted it wrong then, because that is what I meant (or rather, I meant we should set the time back every time we _fixed_ a bug, but that we should not fix any non-critical bugs in the release candidates). I don't see what the problem is, we don't have any financial deadlines, and we have gone more than three years without producing anything even moderately useable - I doubt anything is going to blow up in the next couple of weeks if we take a strategy that a final release can only be a candidate that gets upgraded after we are sure it contains no critical bugs. What we need to ask ourselves is why we are making a even numbered release at all, it's not like we are running out of numbers. Ian says it is because he wants this code to supersede the ancient 0.3 stuff as something stable - which would be credible if he was just going to change a snapshot and some text on the website. But that's not the case: he's already made it clear that he wants to use it as a PR oppertunity, contacting journalists, getting on slashdot, and whatnot. We have led people on too many times. For the last three years, freenet has been shoved on people again and again and again, but we have never been able to produce anything that is actually of any value to anyone. A lot of people will already ignore any news of a new release because of this, and for every time we do it, that number increases. I think this may well be our last chance to get anyone to care what we do. I'm not against making releases for PR reasons - as far as I'm concerned that is the only reason for doing a release. But good PR starts with quality control - if we get a chance in the spotlight, what is wrong with being damn sure that we have something working to offer to people who are lured by it? That means that packages and installers should work well, in both windows and linux. That means documentation for sticky issues (like NATs and setting the nodes address etc) need to directly available to anyone who downlaod. That means we shouldn't be ignoring serious bugs because they appear to be JVM issues (we hadn't worked around any JVM issues in fred, we would have had a beautiful piece of code right now that wouldn't run anywhere). That means we can't ignore the startup time issue, which when we tracked it down comes down to a horribly slow size trim of the routing table - something that is done once every maybe 5 minutes when the node is running and will prevent any routing during the 1.5 minutes it seems to take on a large node. That means we can't release until we have properly made sure that the node does NOT stuff 54 nodes from a seed file into the routing table every time it restarts, pretty much setting it back to square one. And it means we don't release until we are sure that any there are no regressions from previous bugfixes. Time is not critical here. Nobody who cares about a Freenet release today will care less if it comes in a week or two. What is important is the experience of those would be induced to give us another chance by this release - if we burn them again we might as well start packing. _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
