Re: a quick few questions

[Mike Stump <mrs at apple dot 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/.* 
\([0-9][0-9][0-9][0-9]\)  .*/\1/; s/-.*//' | sort | uniq -c
 579 1993
 850 1994
1596 1995
1863 1996
2103 1997
3731 1998
4100 1999
5777 2000
6439 2001
7038 2002
9414 2003
4330 2004

This describes current rates and trends.  Bear in mind that pre 1998 
numbers are a little bogus since we removed old changelog files.

>   We're trying to design a solution that would initially closely match 
> the current "feel" of your existing practices, but that would also 
> enable elaboration and evolution of those practices as the comfort 
> level grew.  Great fun (for us)!

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.  This offers a seemless upgrade to arch for 
people that want to use it even when the `project' is still stuck on 
cvs.  Think sourceforge.

This way, people could use it or cvs, and once they use both, they'll 
tend to continue using the easier tool (if one is easier), quality 
being equal.

> 1) Why is it only overnight?   Why not more frequently?

cron is widely used and known, and triggers builds, and with builds, 
testing.  Engineers like knowing if their `change' got into the build 
or not, this is easy when the rule is easy.  Check in before 6pm, and 
the change will be built and tested, check in after and it won't be.  
Most people engineer environments to be day based, one could have 
10000+ projects (just fill a machine room with tons of boxes), or a 
mere 20 projects (one build machine).  This is a human factors issue.  
A week is too long to provide useful feedback to the engineer, but much 
faster than a day just gets to expensive.

For individual testers that share testing and development on the same 
machine, they know they won't be on the machine from 6am to 10am, so, 
cron is a perfect fit.  They don't want it to impact them and they 
don't want to think about it, so cron is virtually the only way to get 
it done reliably.

>    a) tradition

No, don't think so.

>    b) hw (money and slowest-supported-platform) limits

In part.

>    c) not wanting to read results more frequently

Not the issue as good testing is regression based and doesn't produce 
chatter when testing shows no regressions.  Ideally, we want testing to 
be infinitely fast and continuous, all the time and on all branches and 
source trees.

>    d) having found that more frequent results would
>       simply create too many false negatives (bugs that
>       would have been fixed quickly anyway)

No.

> 2) Is it easy to speed up the testing with more hw and/or
>    with infrastructure additions (e.g., using distcc)?
>    Or, is it generally believed that they run about as fast
>    as they could be expected to?    If they can be sped
>    up, by how much?

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.

>    If it could be sped up considerably, even if only on
>    one or two platforms, then one idea is to make a subset
>    of the testing an _enforced_ part of the commit process,
>    with commits that would cause regressions being rejected.

I'd love to hear from people that lived in this type of world (and our 
style of world) and hear which one is better.  Offhand, it might be 
interesting to try.