[OpenAFS] buildbot and packages

[Troy Benjegerdes]

[snip]
> >> None of those steps knows about another, nor should they. If you want
> >> to enable debugging, just do it.
> >> If you want to provide a script which does debug builds, do it.
> >> Anything else is pointless complexity.
> >
> > Debug symbols are pointless complexity ;)
> >
> > If they are something you are going to ask a bug reporter for, then my
> > argument is ./configure (no arguments) should 'do the right thing' so
> > you can get all the information you need in a bug report with no extra
> > retests required.
> 
> If you know enough to use configure (not a frontend script, but configure) and
> end up with an AFS you install, I assume you have a small amount of clue and
> can deal. If you want to use a frontend script, fix that script.
> 
> > If there's a perceived performance impact to having debug on in a release
> > build, then I want to see a full QA test and benchmark results showing that
> > it's actually slowing things down.
> 
> Well, as soon as you finish it, feel free to share the results.
> 
> We're waiting with bated breath.

Done. http://gerrit.openafs.org/#change,8137

My rate to prove that the perfomance impact of this change is negligible
for most all use cases is $125/hour. If I am contracted to perform a full
QA test and benchmark run for this change, I will refund half of my fee to
the first organization that can demonstrate that they are one of the edge
cases that  does actually see a performance degredation from default debug.

I think I just saved the OpenAFS project at least $25,000 if we skip the
testing and accept the change.

If you want some justification about why I'm qualified for such a rate,
have a look at

http://www.scl.ameslab.gov/Publications/Brett/storage_challenge_sc06_presentation.pdf

You also might be amused to know that work was done with PVFS servers
running using OpenAFS as the root filesystem.

In the meantime, I have a combine I have to get ready to go pick soybeans.