On Sun, Oct 12, 2003 at 05:22:07PM +0200, Menno Jonkers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ian, > > Ian Clarke wrote: > | As unstable's performance improves the notion of separate networks > | looks increasingly less attractive and sensible. > > | [...] There is no reason that Freenet nodes of differing abilities > | can't co-exist in the same network provided that new additions aren't > | so destructive as to take everyone else down. > > | [...] This can form the basis of a test network > > I'm not sure whether you're suggesting to set-up a separate test network > or have these tests run against production. Anyway, I'll spew my 2 cents > below and would be interested to have your vision on that. > > > I'd expect that as the user base and application (i.e. non-research use) > of Freenet grow, the stability requirements of this network & community > will leave less and less room for test activities. Consequently updates > of software should be introduced in a very cautious and controlled way. > With the highly interconnected nature of Freenet this implies a very > high level of quality assurance.
I would like to point out ONCE AGAIN that we are nowhere near 1.0. > > This requires a fundamental change from the current practice in which > debugging is largely performed in the production network, with an > uncontrolled number of "development nodes" with different versions of > software at different levels of maturity. The result is a network that's > basically unmanageable, as underlined by the recent inability to both > quickly identify and resolve a significant loss of performance. A new, > well performing unstable may reduce this pain but will at best postpone > the need for a change. > > Requirements for a production network: > 1) Nodes run only software versions proved stable How do you enforce this? You can't. > 2) The number of different versions in the network is minimal Ditto. > 3) Updates (minor changes) are limited to security & anonymity fixes > 4) Upgrades (major changes) are rare (say bi-annual) and done to only to > software versions proved stable > > Note that 3) implies a production fork. Pretty usual. And all its associated costs. > > But how to prove proper behavior of a new version if you cannot do real > life tests? You probably can't. At some point in time the new software > needs to be exposed to the production network and vice versa. > > A scenario to do this with a minimal risk of impact on the production > network would be: > 1) Development and extensive testing are done on a separate test > network; smoke tests are part of this Local test networks are useful for debugging a certain class of bugs. We do use them from time to time. > 2) Once a version is reached that has shown to work well on the test > network, a feature freeze can happen and this can become a Release > Candidate 1 > 3) A limited number of RC1 nodes is introduced (or upgraded from > production versions) in the production network for a limited amount of > time. Their behavior is observed and analyzed, resulting in bug reports. How is this different to 99% of the network running stable and 1% running unstable? > 4) The RC1 nodes are removed from the production network (or downgraded > to production versions). > 5) It is explicitly decided which bugs are going to be fixed to go from > RC1 to RC2. No other bug fixes or features are introduced: code freeze. This is ridiculous. > 6) RC2 is tested, i.e. goto 3) > 7) Once an RC is reached that seems acceptable for production use, one > could do a large scale test of it on the production network. And if it > runs fine on a large number of nodes for say a month, it could become > the official new release. See above. > > This is a fairly basic software development process (and as always there > will be some discussion on the line between feature and bug fix). Freenet is not Microsoft Word. > > The key things here are: > a) Developers still have a lot of freedom at stage 1) > b) Testing is highly controlled, both in scope and time > c) Whichever person/entity decides what requires fixing at 5) should > /primarily/ represent the interests of the production network. > > Clearly both b) and c) imply changes to the current process. They should > remove much of it's current alchemy. > > > Finally there's the touchy issue of separating networks. There are two > basic routes here, with pros and cons: > > 1) Developers move their activities to a separate test network. Current > Freenet becomes (stays) production network. > - - pro: no impact on the current user base, no need to migrate > - - con: no rapid performance improvement for current user base. Unclear > how to evolve this into clean, few version production network. Requires > developer effort. Test network will be small at first. Test network will ALWAYS be a lot smaller than the mainline network. This will in itself discourage use. Client usage patterns will be different, as will node usage patterns - all the transients and semitranisents (perm nodes that don't run long enough to get many requests etc) will run on the prodnet. > > 2) Users migrate to a new, separate production network. Current Freenet > becomes test network. > - - pro: rapid performance improvement for user base. Clean start for > production network. Minimal effort for developers. Maybe. > - - con: users need to actively migrate. Test network is cluttered with > versions. Psychological effort of "giving up" current Freenet and > "giving in" to dissident users. > > (Work out option 3, two new networks, and option 4, nothing changes > really, yourself.) > > Currently I tend to favor option 2) because it's a clear choice to > satisfy user needs. And in the end that is what software development is > all about. > > Regards, > > Menno -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
