To the Distributed Folding administrators:


I do __not__ understand why updates are under "time pressure". Let us say that the purpose of the project is to find out how (well/poorly) certain software runs. You can determine this from the filesets that the software reports back to you. For the purpose of accumulating / analyzing these reports, does it REALLY matter whether a participant's reports started coming back on Thursday, or on the following Monday ?

My conjecture is that the reason for "time pressure" is a high-minded attempt to be "fair" to all the project participants -- it appears you want to minimize that time interval during which different participants are running different software versions (particularly if the different versions award "points" differently).

It seemed to me the way the betas were introduced -- you announced the availability of the new software, and left it up to each individual to decide WHEN to download that new software -- worked quite well.

--------


I propose formally putting the following question to a VOTE of *all* the DF participants :


Are you in favor of "spreading out" the occurrence of an update, rather than "bunching together" when everybody's downloads occur ? (A "yes" vote would mean that some participants would still be running the old software, while others would already have downloaded and started running the new software.)


--------

If the consensus of the DF community were that "spreading out" would be acceptable, I suggest the principal software change would be to have the server(s) limit the number of "simultaneous" downloads -- as long as that threshold (which could be quite low) was exceeded, the server(s) would respond negatively to an incoming "Checking for new versions" handshake.

What I have in mind is that the "full credit" overlap period between the old and the new software ought to be much more than 24 hours. That would reduce the "time pressure" I've felt with recent updates.


mikus