I'm up for either option, as long as the users get a stable network to use, I've been testing 6233 most of this afternoon, inserts are flying, 92 megs in just over an hour! Wikked! FIW still has issues with my site but that'll get resolved I'm sure. I think once node integration is sorted (I 've still had no inbound insert / request search keys let alone successful attempts though my node is accepting all connection attemps successfully :-/ )
I'd say if these issues can be resolved I'll back this build as stable, and move my now 4 gig store back to the main network as long as develoment nodes are worked on in a separate network, as suggested below. Pete -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Menno Jonkers Sent: 12 October 2003 16:22 To: Discussion of development issues Subject: Re: Smoketests (Was: Re: [freenet-dev] Re: It Has Begun <sigh> -----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. 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 2) The number of different versions in the network is minimal 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. 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 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. 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. 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. This is a fairly basic software development process (and as always there will be some discussion on the line between feature and bug fix). 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. 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. - - 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/iXGe9m/IbJq4o8sRArIZAKDA90w68DKlco/lEndP8cHkESfMbACfc0sf SlA2JCqRSOWsu1PZ9ccn8F4= =MGXr -----END PGP SIGNATURE----- _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
