While it is somewhat surreal to publicly admit, I find myself in complete agreement with Oskar.
--gj On Sunday 20 October 2002 09:04, oskar wrote: > 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 _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
