Re: Winetest: outstanding issues (SERVING)
Brian Vincent wrote: I didn't add in a formal method for doing this, but what we have right now is pretty much two different scenarios: 1) winrash client has never downloaded a test. - so we send them every winetest we have 2) winrash client has downloaded a winetest - we send them only the most current test we know of, then tell them to come back in an hour and check for a new one. I don't understand any of this and it worries me. Do you mean separate tests, like "kernel32_crosstest.exe", or do you mean "winetest.exe"? Because if you mean the former, we have no mechanism for sending these one by one. If you mean the latter, I think it's a mistake to send anything but the latest winetest.exe. The idea is to evolve winetest.exe quickly, not pondering over old broken releases... If you mean something different entirely, I would be glad for an explanation. :-) regards, Jakob
Re: Winetest: outstanding issues (SERVING)
As it was written in the Book of Jakob Eriksson <[EMAIL PROTECTED]>: > I don't understand any of this and it worries me. It's ok, really ;) > Do you mean separate tests, like "kernel32_crosstest.exe", or do you mean > "winetest.exe"? The two examples I listed are the only two things we support right now, Chris can update his winrash clients automagically (we've actually had this functionality from the beginning, this was a small tweak.) What the changes really boil down to is this.. Paul is doing winetest.exe builds that can be hooked into his Wine Regression Testing framework. That means we get builds triggered 2 - 5 times a day as Alexandre does batches of commits. Kevin is doing winetest.exe builds at some set time each day (4am EST or some such.) These provide a baseline for Paul's. If something breaks at this level we can look at Paul's results for more granularity. The changes today will always distribute the newest winetest.exe to the winrash clients. I think we're all on the same page here about that. Dimi - when we get Kevin's builds available and we verify error reporting is working, let's try to get a good test of everything done. It would be nice to get this done by Sunday. -Brian
Re: Winetest: outstanding issues (SERVING)
As it was written in the Book of "Dimitrie O. Paun" <[EMAIL PROTECTED]>: > What we need to support: > -- multiple publishers > -- multiple files for the same build for each publisher > -- various distribution policies Okay, this is mostly done. Please note the following changes that must be done in the publishing mechanism: 1) Add a publisher parameter with your name, such as: http://test.winehq.com/service?publish=winetest&url=http://my.url/winetest.zip&publisher=paul Possible choices for publisher: "kevin", "paul", "chris", case sensitive 2) If you stick an exe in a zip file, it must have the same filename as the .zip, just with an exe extension. So, winetest-20040423-0859-blah.zip must contain winetest-20040423-0859-blah.exe > We can have different distribution policies: pick > a random file, send all files, etc. Given that we > have few published files, and tests are short, I > suggest we send them all. So what we have to do is > to add a loop around most of the script generation: I didn't add in a formal method for doing this, but what we have right now is pretty much two different scenarios: 1) winrash client has never downloaded a test. - so we send them every winetest we have 2) winrash client has downloaded a winetest - we send them only the most current test we know of, then tell them to come back in an hour and check for a new one. I think this will be sufficient for quite a while. -Brian "Who's getting ready to go on vacation and won't be around." Vincent
Re: Winetest: outstanding issues (SERVING)
And the thrist and last installment: SERVING (Brian) --- What we need to support: -- multiple publishers -- multiple files for the same build for each publisher -- various distribution policies What we need to do: -- maintain a pool of releases as described in my previous mail. This is a map/hastable keyd by the published filename. -- persist this to disk, in case of server crash, load it from disk on startup. -- currently we use /url.mask to get to the url mask. We need to add the publisher info in there, so this will need to change to: //url.mask Similar for the other files. -- the rest remains unchanaged, as Brian correctly mentioned. We can have different distribution policies: pick a random file, send all files, etc. Given that we have few published files, and tests are short, I suggest we send them all. So what we have to do is to add a loop around most of the script generation: for file in pool: generate script commands to download it and run it It looks like there aren't that many changes after all. -- Dimi.
