Suggestion: A way to do betatesting

I posted this in another thread previously, but it sorta drowned because of a lot of other stuff, so I'll try again with a new thread :)

Betatesting has been discussed before and this is yet another suggestion

Since it is not really possible to setup a test server so we could test new releases before they were released, I'm thinking of doing it differently. When we change to a new protein, it's possible to upload "old" data for the next 48 hours. Why not use part of that time to beta test?

Besically, it should be possible to set a "beta switch" in the client. If true, the client will load the update right away, if false, the client will continue crunching on the old protein for a little longer - how long I don't know, maybe 12 hours or something?

That would make it possible to report bugs and get them fixed before the majority of the clients is starting to update.

It would also distribute the load on the server, at least a little bit

Stupid idea or?

Ps. Howard, I sent you an email with a link to a broken install. Can I expect to get an email when you've downloaded it?

Isn't this essentially what we are already doing? :rotfl:

I am not reading the trades@mshri.on.ca e-mail (Elena is handling that), but if it is from the last client you can delete it as only bugs from the current release will be investigated since we fixed a lot of stuff.

Howard, what pointwood meant was IMHO: when you publish the new version don't automatically force all the clients to upgrade themselves right then (unless they have this beta-switch) enabled. Wait for 12 hours or so for users to check if it's running and then send this "please autoupdate" message to all the clients (as it happens right now every time when the client "checks for a newer version").

On the other hand, didn't some users have access to the new client prior to the last update (I remember somebody mentioning IronBits and others got some kind of Beta version prior to the last protein update, but I could have misunderstood something)

Quote:

---

Originally posted by Brian the Fist
Isn't this essentially what we are already doing? :rotfl:

---

Erhm...did you "read" this before you had your first cup of coffee? :sleepy: ;)
Unless the client have some kind of secret switch that's not described in the readme, then no ;)

Wirthi is correct. When you, the ruler of the DF servers, decides it's time for a protein change and you release a new protein, then the normal clients should ignore the update for the first 12 hours (or whatever will be considered enough time to report evt. bugs and release a bugfix). If a user have added a switch (let's say -beta) to the foldit script, then it will grab the update right when it is available. Those "betatesters" will then be able to report back whether the update went ok or they found some kind of bug. If they found some kind of bug, then you would be able to fix that before the majority of the users starts upgrading (so only limited damage was happened), plus you would get a lot less hate mails :D

Maybe it would even be possible to simply add 12 or 24 hours to the current 48 hours changeover periode and then use those extra hours for it :dunno:

Got your first cup of coffee now? :rotfl:

EDIT: Nevermind that last part - got an email now :D

As usual here, it was case of PEBKAC :D

:Pokes: Howard ;)

I did think of a way this could potentially work with a minimal amount of effort on our part (always a prime concern of course :D ). Basically it would work the same way how people running the update proxy get the updates earlier on, it could even look for the same signal. The only issue is we have no way for the server to accept new versions of the new protein while still processing the old one. We'd have to stop accepting the old protein if we are to begin the new one, even if its beta testing only. Unless it went to some other beta site or something. Anyways, gotts think about it a bit more still before that could be implemented

Quote:

---

Originally posted by Brian the Fist
The only issue is we have no way for the server to accept new versions of the new protein while still processing the old one. We'd have to stop accepting the old protein if we are to begin the new one, even if its beta testing only.

---

Hmm ... you accept "old" proteins up to 48 hours after the update. Is this limitation also true for this perio? I mean, you accept the result and adjust the stats but don't use these structures for the science (since the server can't handle them any longer?)

Perhaps putting the duration of this beta-phase to a very short time (till the first, fast clients have reached gen. 5 or so) would help? Just to test the update is going smoothly and the first few generations can be calculated without any crashes?