To the devs working on fred, I hope its clear that we do appreciate the effort. We wouldn't be here if we didn't think the countless hours people have volunteered on this project were making Good Things Happen. We understand that even development on code that people on a production network wouldn't see right away is important, as we trust y'all know what you're doing and are Fighting the Good Fight. This is a hard problem being worked out here - operational maintenance for an emergent, open source p2p network isn't the most well understood software engineering discipline. (I have particular interest in seeing how this will work out too...) > My main concern with having separate networks is that it becomes > virtually impossible to determine whether the development build > is performing better or worse than the stable builds because they > will be separate networks with different usage patterns. I understand this concern, and I think you do bring up a good point. What I would suggest though is that while usage patterns on development and production networks most likely will vary, debugging on the development network will be much, much simpler because: *) all nodes are of a known reasonable build and proper behavior is easier to verify *) a small suite of "things to test" could be used to verify that proper behavior exists, rather than relying on production users to do the verification. This doesn't require any new code (but automation would of course help), just a checklist - "startup works", "inserts works", "retrieval works", "arks work", etc. Or are there issues that really and truely vary based on usage patterns that cannot be replicated? I don't think the devl network would be too small either - I'd suspect everyone interested in testing it, anyone dissatisfied with bugs in the production network, as well as all developers would be running (at least) one node. > There is, however, the advantage that we can get away with a > much stricter upgrade regime in the unstable builds, I would > almost advocate making the lastGoodBuild the current build -3 > by default in a dedicated development network. This in itself is a good idea, though as currently implemented, this only is used during the announcement phase (once a node is in the routing table, they're talked to). I've also heard that there bugs in that part too. What would be desireable would be a hard limit: dont make any connections to or from nodes below Version.buildNumber-3. I'll put together a patch for this if there's interest. > Another thing to consider is how we handle the transition from > the current architecture. What I'd suggest won't be a very popular view, but I think it may be for the best. I think you're right in that there should be a devl network for unstable, forcing upgrades within 3-5 builds. This network should be seperate from the existing one, as the goal is to test the build, not to do general freenet browsing (right?) I'd also suggest that there should be a new production network that forces upgrades within 3-5 builds, based off some yet-to-be-determined build. This network cannot be the existing freenet network, unless it drops references to and refuses connections from old nodes, as otherwise there would be the same problem we have now - it would be exactly like running stable. If the production network "is" the current network but forces upgrades via buildNumber-3, isn't that functionally the same thing as a new network? The existing network would, therefor, atrophy, with people migrating to one (or both!) of the new networks (prod and devl). One reason why that idea sucks is that existing passively operating nodes become useless. That is a problem, but those nodes are most likely very old (<=598) and may be doing harm to the network anyway. A possible migration path for upgrading the prod network from unstable could have four phases: 1) the devl code is hacked upon, fixing bugs, adding features, tuning performance. 2) the devl code is frozen and tested against the devl network 3) disable the "last good build" enforcement in the devl code and run it on the production network for 3-5 (7?) days, verifying that its behavior is proper and that its an improvement. 4) once the devl code has been burnt in, roll it out to production as a manditory upgrade. imho the rate of stable rollouts as of late is most likely a good pace (monthly?). I think going this route may be worthwhile now, as freenet has reached a certain level of maturity with which these sorts of release engineering processes are appropriate. Anyway, thats my take on things. Thanks for your openness to keep this under the freenet umbrella - no one wants to fork off at all, we just want to find a way to get freenet back to the reliability and performance we used to have. -jrandom
!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ CryptoMail provides free end-to-end message encryption. http://www.cryptomail.org/ Ensure your right to privacy. Traditional email messages are not secure. They are sent as clear-text and thus are readable by anyone with the motivation to acquire a copy. !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
