Ed Tomlinson wrote:Surely the problem is not that the latest unstable build does not work. The problem is a) that there a lot of different builds which do not work in various interesting ways, and interfere with each other, and b), hardly anyone has a working build any more.
On October 07, 2003 02:52 pm, Toad wrote: [...SNIP...]
In this I agree with toad. It is going to be a very hard slog to get new code tested and debugged in a developer only network... Old builds were replaced because they were buggy. Going back is not going to fix thoseThe basic problem we have been having is that the stable branch does not work. If the stable branch worked, I would be able to commit disruptive changes to the unstable branch without exploding the list. As it is, I should have tested the changes on a local test network before committing them (not like anyone else here does). The solution is to debug the unstable branch, and get it good enough to merge. If people want to set up an independant network that uses prehistoric builds, that's fine, but if everyone uses them, I don't see how we can possibly move forward, for the reasons I just outlined.
bugs. Instead we will have people complaining that freenet eats to much
cpu and has other (long fixed) bugs.
What we have not is not working well. IMHO we need to put efforts into
fixing this. This means freenet will have problems for the next couple of
days (or maybe weeks, but I hope not). I can live with it.
Hopfully we will be able use more small test nets to verify basic functionality
before realeasing into the wild. This implies we need some sort of testing
script that can be executed automaticly on a test network. I think testing of
this type would lead to a much more stable network. Before you say but thats a developer network - its not. I would start from a standard set of datastores and do a common set of operation on the nodes
measuring results. For instance:
do inserts work?
are they faster/slower than the last test (what is the trend)?
do retrieves of known data work?
what is the performance trends?
is FEC working?
and a bugs are found we add tests to try and catch them before we (re)release
code with problems.
This would imply that new code would get tested before being placed in a snapshot. Comments?
That sounds right to me. The main objective should be to fix existing bugs and to reduce the chance of releasing a highly buggy version "into the wild" in the future.
I think Toad (or someone) has mentioned a "smoke test suite" before as an objective. That sounds to me like what you're suggesting.
Having never tried such a thing, my question is: how would you run the test to see that, for example, inserts are faster/slower than the last test? Doesn't that mean you have to run a large private network of computers to see how it works? Or instead, can you get away with running a very small network (maybe even on the same machine) where you build in artificial delays to simulate the "real-life" delays in a larger network?
I'm not criticizing the idea, I'm just trying to draw out some details so we can see that it'll really work.
-Martin
New suggestion:
1. Force everyone to use an old but functional build (692 or 598 for instance [1]), *or* one of the latest (say) 3 unstable builds.
2. Prevent Fred from communicating with any node not in the above set. (Would need a detector in production Fred to respond to a current permitted unstable build number signal, which for now would have to be issued from a central site)
Presumed results
a) The vast bulk of, say, 598 nodes form a functioning network.
b) The development builds are unlikely to be numerous enough to damage this network, but, if they do, the build number can be raised immediately to disenfranchise the harmful build as soon as the signal is received (see above).
c) I thought NG Routing was supposed to be able to work even surrounded by really stupid nodes, unless they actually DOSed each other, which 598 probably didn't, so you could carry on developing NGR on the main network.
[1] It would be nice if 5028 worked, but I submit that a major reason for the current debacle is that it doesn't.
-- Roger Hayter _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
