Re: a quick few questions

[Tom Lord <lord at emf dot net>]

    > From: Mike Stump <mrs@apple.com>

    > On Jun 23, 2004, at 12:36 PM, Tom Lord wrote:
    >> We're trying to infer reasonably well the scale and scope of GCC 
    >> (e.g., what's the commit rate tomainline?).

    > $ cat `find . -name \*ChangeLog\*` | grep '^[A-Z12]' | sed 's/.* 

Neat.  Last time I measured I sampled the commit list which also gave
an envelope-sized picture not only of annual rate by the rate as it
varied over a day or over a release cycle.  Somewhere in some archives
are my notes -- it wasn't a very comprehensive study but I found it
interesting.  Your alternative-technique ~1/hr in recent history
sounds familiar to me but perhaps that is just wishful remembering.

    > You might be able to get people to `switch' to arch, if arch could 
    > mediate checkins to the cvs server and re-pull from it to populate the 
    > arch version of the repo.  

There are some tools around for that and they'll get a bit better (and
some new approaches will be tried) before any are shipped with arch.

I'm not sure that there's ever really going to be any "universal
adapter" for that gateway functionality.  There are too many ways to
use CVS and to manage patch-flow in projects.  A lot of site-specific
configuration may be needed in every case to obtain particularly nice
results.  (Correlative evidence: if such universal gateways encouraged
migration, BitMover would be incented to build one too.  But instead
they built a site-specific semi-gateway, just for the kernel.)

>From the perspective of arch maintainer seeking maximal adoption, my
most frugal path _might_ be to keep gatewaying a low priority and to
concentrate instead on making a pure-arch environment sufficiently
inviting that en-masse migration to it is a plausible, indeed
attractive option.   This is not to discourage potential early
adopters who are willing to endure setting up "glue" themselves in
order to try arch out.

On the other hand, from the perspective of some arch-users, there is
money to be made setting up custom gateways.  There is an existing
market for that kind of arch expertese.  (No, I do not make referals
or provide solicited recommendations except for a very few people who
know who they are already.)


    > Ideally, we want testing to be infinitely fast and continuous,
    > all the time and on all branches and source trees.

Noted.  I find it hard to spot ways to say something smart about the
"value curve" of that: how much is a 50% testing speed-up "worth",
today?  What's the return and who's paying?  Hence "what's the
budget?"  -- before we can think about what should be done.

It could, but I doubt will, just sponetaneously emerge out of
volunteerism, whether private or corporate.  The excellent donation
last year to FSF-france for testing stands out as a pretty exceptional
event.  So a case for business or charity needs to be made to
_someone_.  But that's hard to make in a simple way with such
uncertain ideas about maximizing "return".



    > gcc testing can be sped up 10x, if someone wanted to do that.  The 
    > transition from /bin/grep to grep alone was a massive hit.

Wow! :-)   (Have you tried moving '/bin' to the front of your $PATH?
Are you using some filesystem whose caching is ineffective wrt. iname?)

-t