[pypy-dev] change of strategy for the py3k branch?

[Laura Creighton]

About 25 years ago (dear god that makes me feel old) when CVS was the
new and happening thing in version control systems, we were in the
really bad problem area at Human Computing Resources of porting unix
to more than 1000, kid you not, of different M68010, M68020, NS16032,
NS32032, Zilog-I-forget, MIPS, and I forget what other hardware-based 
systems, with completely crazy combination of graphical cards, interrupt 
driven weird hardware and well, trust me, it was a mess.

We wanted one kernel that we could deploy everywhere.  This was impossible,
but we got the best we could do, given our constraints by changing the whole build system to one in which you typed 'make'

and it started by copying all the files from our home repository system 
to a complete and brand new file system, and then copying all the tests
to the same system, and then running the tests that ran before you tried to
compile a kernel, (mostly having to do with seeing that your hardware was 
sane and that the setup script worked, and was happy with the results) and 
then you made your kernel.  Which could take more than an hour.  And then you
ran your kernel tests against the new kernel (which happened overnight).  In
the morning we had a whole new set of errors to deal with.

I don't think that we have reached this level of complexity with PyPy yet,
but it is something to think about.  The time of 'everything is a i386' is
over now, and it is not clear how this will play out in the realm of systems
and even application programming languages.  Clearly not as badly as we had it
when we were making kernels as quickly as we were being sent hardware, but
there still is some effect.

Laura