Win32 packages released on sourceforge

[Paul Millar]

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