Hi Dimi,
On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
Anyone should be able to reproduce the output by extracting this date (from the .zip filename, or from winetest.exe), "cvs up -D"-ing and cross-compiling themselves.
There are several problems with a variable build time, but the biggest one is that one can not tell when Alexandre finished the commits for the day just by looking at wine-cvs messages.
Does this *really* matter? If we miss some patches, then WRT will just rebuild when it finishes the current cycle. The resulting binaries would be published once it done.
If you look back 5 years, you will not see a single instance of commits at say 4am, yet there will be plenty of examples where any (not overly complicated) algorithm will fail to detect the end of the commits for the day.
Errr, 'fraid I don't see the 4am part (unless you mean at precisely 04:00:00). Taking data from the past year from: http://www.winehq.org/hypermail/wine-cvs/ Downloading the "downloadable version", and running a wee 1-oner: grep -h Date: 200[34].*|cut -d: -f2-|while read d; do date -d "$d" +%k >> output; done; sort -n output | uniq -c | awk '{print $2,$1}' > commit.dat Gnuplot it with: plot [-0.5:23.5] "commit.dat" not w boxes The results are: http://www.astro.gla.ac.uk/users/paulm/cvs_commit.png There's actually a peak of commits at 4am.
This is of course all UK local time. Do you mean 4am in one of the US-time-zones? (=> ~ 9am-11am or so?).
Hmmm, in the past year there've been patches a 7am, 8am, 11am and 13am. There haven't been any 9am and 10am, but looking at the data it wouldn't be impossible for Alexandre to commit at usual hours of the day or night :)
The build is time consuming, and it will take the better part of the day to do a proper: build, distribute, test, gather results cycle.
Actually, the build time isn't *that* time consuming. Running ccache and distcc, it currently takes about an hour to build both native and cross-compilation. With a bit of effort, I'm sure that could be improved a fair bit. As soon as the cross-compilation is finished, the binaries are available to be published.
The time-consuming bit at the moment is running the tests within wine, which is bad because of the way that's done within WRT. That needs fixing, but it's largely independent of the cross-building, publishing steps.
We gain almost nothing with a CVS-based trigger, other than unwanted variability. Having a well defined nightly build just simplifies everybody's life, it's simple to document, and understand. Please lets not complicate things just because we can.
Well, the CVS-based trigger is already implemented, debugged, tested and works. Making it trigger at a fixed time would be fairly easy to do, but involves changing something that's working. But making the time fixed isn't necessary, and just give us a potential point-of-failure.
---- Paul Millar