Testing

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> >> How many of your changes need to actually hit the repo in less than 24 
> hours?
> > Depends on whether you think rapidly clearing bugs is important.  I do.
> 
> Why is that important?  My 24 hours was a guess at the long tail.  Who is 
> going to notice if you fix a bug but it doesn't appear in HEAD until one of 
> several other people respond and poke a button on a web form?  It may take 
> another mailing list to help things along.

Prompt response to a user-visible bug is the case I was thinking of.
Hans Meyer's rash of small problems with ntpq, for example, all pretty
trivial once chracterized.  He was being so helpful that I put a high value
on addressing his issiues immediately, giving him rapid confirmation that
we cared about his issues and were on top of them.

To a lesser extent this applies to anything that arrives on the issue
tracker, I mean, as opposed to long-term development work.  I want us
to get a reputation for respomsiveness, and "Fix waiting on review"
doesn't have quite the same oomph as "Fix pushed."

> > I'm really, really reluctant to consent to a policy that increases my
> > process friction.  My experiences with the consequences of that kind of
> > choice have never been positive.
> 
> How important is your individual way of doing things?  Would you be willing 
> to tolerate some inconvenience if that made the rest of us more productive?

In principle, yes.  I'd need to be persuaded that the net was positive -
that the rest of you got sped up more than I got slowed down.  Past
experience makes me skeptical of such claims.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.