[M3devel] Hudson structure?

[Jay K]

> I thought I had explained that some time ago, but maybe I forgot. So here
> is the gist:
>
> o current, last-ok, prev-ok are all complete package pools + compiler that
> contain a complete cm3 installation
> o for builds, current is initialized from last-ok; then packages
> are built and shipped to current
> o if a build succeeds:
> - prev-ok is replaced by last-ok
> - last-ok is replaced by current
> Thus we should always have a backup for recovery in case something
> goes wrong. And last-ok should always be exactly what its name
> indicates (the last working version) (it seems that this invariant
> sometimes does not hold :-/)
> o tests usually just use last-ok


Do we need all this?
I guess it is ok. There should be just two when idle and three during a build.
 But there are more than that currently, more than what you list.


But we don't need them to be complete.
They can all just contain cm3, cm3cg, mklib (for a few targets), m3core, libm3.


More generally I thinking of digging into the Hudson stuff.
I think I know what to do about cm3cg, at least.


There are two kinds of "ships" or installs.
There is ship/install on top of the "currently running" install,
and there is install to other than it, possibly to a directory that started empty (recently).


Shipping of cm3 doesn't do anything.
This could be viewed as a limitation -- the comments indicate it is at least partly
due to shipping in-use files doesn't work on some operating systems (not just Windows,
in fact, it is easy to do on Windows -- rename away first).
However it is also a good thing.

Shipping of m3cc/cm3g does do something.


I assert that shipping either of cm3 or cm3cg on top of the "currently running"
install is wrong.


Shipping into other, a new empty directory, is perfectly fine.
In fact, a good metric might be, in both cases, to ship as long as the destination doesn't yet exist.


For the "currently running" install, ship should do nothing, and should instead be done
"outside the usual system" via sh/python.
Exactly as we do for cm3 already. But that should also be how cm3cg is dealt with.
And the config files (I suspect also already the case).


That way they can be updated together.  *** the very important point **


Related question: now that we have far less frequent builds, can we merge the m3cc and build Hudson tasks?
I'd like there to be as few of tasks as possible.
"Multiplication is bad", so to speak. Multiplying work, combinations to test, etc.
Though granularity is also nice -- if some things are broken, still nice to see some tasks succeeding.


Related: we currently keep all snapshots on the build machines.
We shouldn't keep so many.


 - Jay