Hi, I believe this email to be extremely accurate and well written. It echos many of the calls we have been making over the last few days regarding a production network, and I would particularly like to draw attention to: >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.
I believe that without a clear definition between testing and stable networks, recent occurrences regarding network degradation are bound to happen again, sooner rather than later. Much better, then, to push to a stable "clean slate" with the next well-tested stable build, and always maintain this migration step with each significant new stable release. It is definitely time that new procedures were put into place to safeguard network performance and the freenet userbase, especially if any truly worthwhile content is to surface in our network. --Reskill On Sun, 12 Oct 2003 08:22:07 -0700 Menno Jonkers <[EMAIL PROTECTED]> 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. > >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
