Win32 packages released on sourceforge

[Paul Millar]

Hi Dimi,

On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
> On Mon, 22 Mar 2004, Paul Millar wrote:
> > Does this *really* matter [if] we miss some patches?
> 
> Yes, it does matter, and it's rather important. The test cycle is
> non-trivial, as I've already noted. It will take many hours to
> distribute and run the tests. 

I'm afraid I still don't see why it should take hours.  The binaries
should be available for the client to download a minute or so after the
compilation finishes.  The clients can run the code whenever their users
decide: we have no control over that.  We should just collect the results
and put them into the DB, along with which patches have been applied (like
tinderbox).

> The clients can (and most likely) will schedule their local daemons to
> run only during certain timeframes (when they don't use their boxes).
> This means that we can expect a full test cycle to take close to 24h.

Yes, one possibility is for client code to be configured to poll for a
certain period, say 9pm to 6am (assuming the PC is left on overnight).  
The 11pm poll could pick up an early build and the 3am one could pick up a
later one.

But ultimately its the end-user's choice when the winetest.exe code should
be downloaded and run; we can't mandate this.  The best we can do is try
and utilise that time as effectively as possible, which means building and
distributing winetest.exe as quickly as possible.

Dictating a specific build-time limits us to a single cycle per day.  If
people were willing to allow the client to poll over night, we couldn't
make use of that.  It also forces everyone to test at about the same time.  
4am is OK for people in American, but its terrible for Europeans.


> I don't want to have some clients go off and test on a spurious build.
> We have _one_ shot per day for a build, and it better be the right one.

Ah!  Perhaps this is the misunderstanding: they're not "spurious" builds,
they're builds with less patches applied.

If there's a problem, then a build with less patches is valuable.  If it
passes, then it tells us which patches are not the causing the problem, if
not then there's less patches to search through for the problem.

Either way, it narrows down the problem without developer's having to
think about it.  Developer's time is precious and should be spend doing
"difficult" problems, not doing trivial things like tracking down which
patch caused the problem. :)


> > 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?).
> 
> Yes, I meant EST. Or, as you can see from your graph, 10am GMT is perfect.

OK.  Its also the most likely time by which Alexandre has committed all
the patches for that night (although it doesn't guarantee it).  If we had
to have a fixed build time, its the best time; but I wouldn't describe it
as perfect (but maybe that's just me being awkward :^)

----
Paul Millar