On Sun, Oct 20, 2002 at 03:04:51PM +0200, Oskar Sandberg wrote: > 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).
This kind of strict release criteria is inappropriate for software at Freenet's current stage of development. Its only effect would not be to lead to a more stable release, but simply to discourage minor bug-fixes for a week, leading to a *less* stable release. > 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. It doesn't take a week to do this, my proposal allows for 5 days. Setting a fixed deadline encourages people to test much harder than they might under your push-back scheme. 5 days of hard testing is worth a month of people desparately trying hard not to find serious 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. I find it the height of hypocrasy for people to be so critical of my efforts to educate the public and attract attention to this project. Of course it is easy to scream "PR Whore" and get applause from the peanut gallery, but this project would be dead long ago were it not for the publicity we have received. Oskar, you personally were funded to work for two months on this project using donations that came from people that were attracted to this project through my PR efforts, and the project benefited greatly from it. Similarly, the only reason we got out of the malaise that we were in only 6 weeks ago is because we were able to pay Matthew to work full-time on the DataStore, again this wouldn't have been possible without the donations which were generated by my efforts to publicise the project. > 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. Rubbish, if you ever actually used Freenet you would know that we currently have an active and enthusiastic user-base. Not once has a point release of Freenet suffered from a bug that was created by a regression in the week prior to release. At best, your strategy creates a false sense of reliability about a piece of software that is *STILL IN BETA*. > 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 see no evidence for that whatsoever. > 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? I agree, but those controls should be reasonable and appropriate to our software and its current state of development. Your strategy isn't. > 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. Such information is available on the website. If you feel it is inadaquate - you have editor privs for the website, you should be fixing it or asking others to. > 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). I am not aware of any such bug at this time. > 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. This could be fixed in half the time it took you to write this email. > And it means we don't release > until we are sure that any there are no regressions from previous > bugfixes. This could easily be achieved in a couple of days of hard testing - a week is excessive. > Time is not critical here. Nobody who cares about a Freenet release > today will care less if it comes in a week or two. A hard deadline *is* critical to any release, a deadline which is only pushed back if there is a very serious problem, and a deadline where there are strict criteria about what may and may not be checked in before it. Your attitude will lead to the release perpetually being two weeks away. > 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. I don't know where you suddenly aquired your deep spiritual understanding of our user-base, given that you have never, to my knowledge, actually used Freenet, nor do you subscribe to the support mailing list - but I am not aware of a single user complaint which arose from a regression in a release caused by a bugfix in the week prior to release. I am aware of many complaints caused by bugs that are now fixed, such as the DSB, I am aware of many complaints about the unfriendliness of the Freenet mailing lists and IRC channel, but not a single complaint about something that would be prevented by your proposal. Ian. -- Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] Latest Project http://cematics.com/kanzi Personal Homepage http://locut.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021020/426739ae/attachment.pgp>
