i mentioned this to scott rifenbark privately a few days ago, but i
figured i might as well antagonize a few people on the list by saying
it publicly -- the yocto FAQ as it stands is pretty much worthless.

https://wiki.yoctoproject.org/wiki/FAQ

by way of explanation, i'll reproduce the first part of the superb
foreword in the subversion red book:

===== start =====

A bad Frequently Asked Questions (FAQ) sheet is one that is composed
not of the questions people actually ask, but of the questions the
FAQ's author wishes people would ask. Perhaps you've seen the type
before:

Q: How can I use Glorbosoft XYZ to maximize team productivity?

A: Many of our customers want to know how they can maximize
productivity through our patented office groupware innovations. The
answer is simple. First, click on the File menu, scroll down to
Increase Productivity, then…

The problem with such FAQs is that they are not, in a literal sense,
FAQs at all. No one ever called the tech support line and asked, “How
can we maximize productivity?” Rather, people asked highly specific
questions, such as “How can we change the calendaring system to send
reminders two days in advance instead of one?” and so on. But it's a
lot easier to make up imaginary Frequently Asked Questions than it is
to discover the real ones.

===== end =====

in other words, a *good* FAQ might be:

"how can i use the yocto prebuilt toolchains to save build time?"

a *bad* FAQ would be:

"Does the Yocto Project have a special governance model, or is it
managed as an open source project?"

the kicker is that that last question is, in fact, in the yocto FAQ,
along with a number of other questions that have never been asked by
anyone in the history of the planet. i chat about yocto with people
on a regular basis, and i can assure you, not a single one of them has
ever asked, "hey, rob, can you explain yocto's governance model?"

no, what they ask is, "hey, rob, how can i add a single package to
an existing target?" a question that, i should point out, is not
answered definitively in the existing docs *anywhere*.

anyway, coffee is ready so i'm going to pour a cup and get back to
work. you're now free to yell at me.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On 26/06/12 10:09, Robert P. J. Day wrote:

snip...

in other words, a *good* FAQ might be:

"how can i use the yocto prebuilt toolchains to save build time?"

a *bad* FAQ would be:

"Does the Yocto Project have a special governance model, or is it
managed as an open source project?"

the kicker is that that last question is, in fact, in the yocto FAQ,
along with a number of other questions that have never been asked by
anyone in the history of the planet. i chat about yocto with people
on a regular basis, and i can assure you, not a single one of them has
ever asked, "hey, rob, can you explain yocto's governance model?"

no, what they ask is, "hey, rob, how can i add a single package to
an existing target?" a question that, i should point out, is not
answered definitively in the existing docs *anywhere*.

I would go as far as saying this is the most asked question on the list and definitely a good candidate for the FAQ.

Along with:

Why does package XYZ get built when XYZ has nothing to do with the image I imagine I am building.

anyway, coffee is ready so i'm going to pour a cup and get back to
work. you're now free to yell at me.

rday



_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

--

Jack Mitchell (jack@...)
Embedded Systems Engineer
http://www.embed.me.uk

--

On 26/06/12 10:09, Robert P. J. Day wrote:

A bad Frequently Asked Questions (FAQ) sheet is one that is composed
not of the questions people actually ask, but of the questions the
FAQ's author wishes people would ask. Perhaps you've seen the type
before:

Nice quote, but unfortunately based on the literal meaning the acronym
rather then insight into the function of a FAQ; asking the right
questions is far more important than finding answers ... ;-)

"how can i use the yocto prebuilt toolchains to save build time?"

Perhaps your question is not asked frequently enough to merit inclusion
in a FAQ, or perhaps it's an a far too advanced topic for a FAQ?

a *bad* FAQ would be:

"Does the Yocto Project have a special governance model, or is it
managed as an open source project?"

Just because you are not interested in the answer does not make it a
question you should think about ...

no, what they ask is, "hey, rob, how can i add a single package to
an existing target?" a question that, i should point out, is not
answered definitively in the existing docs *anywhere*.

There are two correct answers to this: the first one is RTFM; the second
one is that if you want an explicit link to the section of the manual
that explains it to be included in the FAQ, you should write the
appropriate entry for the FAQ and contribute it instead of ranting on
the list.

Tomas

On Tuesday 26 June 2012 05:09:34 Robert P. J. Day wrote:

in other words, a *good* FAQ might be:

"how can i use the yocto prebuilt toolchains to save build time?"

a *bad* FAQ would be:

"Does the Yocto Project have a special governance model, or is it
managed as an open source project?"

the kicker is that that last question is, in fact, in the yocto FAQ,
along with a number of other questions that have never been asked by
anyone in the history of the planet. i chat about yocto with people
on a regular basis, and i can assure you, not a single one of them has
ever asked, "hey, rob, can you explain yocto's governance model?"

no, what they ask is, "hey, rob, how can i add a single package to
an existing target?" a question that, i should point out, is not
answered definitively in the existing docs *anywhere*.

You bring up a valid point, but I think it might be worth mentioning that the
current FAQ evolved from a much less technically-oriented version that was
produced when the project launched. At that time some people *were* asking the
kind of questions that you're deriding. I think there's still a section of the
*non-technical* audience who are interested in answers to those questions.

I suggested to Scott R previously that it might be worth having a project FAQ
(i.e., what is this project about, what is it intended to be used for etc.)
and a separate technical FAQ which answers the kind of questions you are
expecting and that we see often on the mailing list. I think one of the
reasons that hasn't been done is that we're hoping to introduce a Q&A function
on the website similar to StackOverflow, where everyone can participate but the
most appropriate answers bubble up to the top. As yet this has not been
implemented and I'm not sure when it will be, so it may still be worth looking
into a static technical FAQ on the wiki until it is.

Scott, what do you think?

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On Tue, 26 Jun 2012, Paul Eggleton wrote:

On Tuesday 26 June 2012 05:09:34 Robert P. J. Day wrote:

in other words, a *good* FAQ might be:

"how can i use the yocto prebuilt toolchains to save build time?"

a *bad* FAQ would be:

"Does the Yocto Project have a special governance model, or is it
managed as an open source project?"

the kicker is that that last question is, in fact, in the yocto FAQ,
along with a number of other questions that have never been asked by
anyone in the history of the planet. i chat about yocto with people
on a regular basis, and i can assure you, not a single one of them has
ever asked, "hey, rob, can you explain yocto's governance model?"

no, what they ask is, "hey, rob, how can i add a single package to
an existing target?" a question that, i should point out, is not
answered definitively in the existing docs *anywhere*.

You bring up a valid point, but I think it might be worth mentioning
that the current FAQ evolved from a much less technically-oriented
version that was produced when the project launched. At that time
some people *were* asking the kind of questions that you're
deriding. I think there's still a section of the *non-technical*
audience who are interested in answers to those questions.

i'm sure there's a place for those less technically-oriented
questions, but i will point out that on the main yocto docs page:

http://www.yoctoproject.org/documentation

you read:

"And, you view a list of commonly asked questions with their answers
by looking at the FAQ."

which, at the moment, simply isn't true. in any event, that's my
$0.02 worth. movin' on ...

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

Op 26 jun. 2012, om 11:09 heeft Robert P. J. Day het volgende geschreven:

i mentioned this to scott rifenbark privately a few days ago, but i
figured i might as well antagonize a few people on the list by saying
it publicly -- the yocto FAQ as it stands is pretty much worthless.

https://wiki.yoctoproject.org/wiki/FAQ

by way of explanation, i'll reproduce the first part of the superb
foreword in the subversion red book:

===== start =====

A bad Frequently Asked Questions (FAQ) sheet is one that is composed
not of the questions people actually ask, but of the questions the
FAQ's author wishes people would ask. Perhaps you've seen the type
before:

Q: How can I use Glorbosoft XYZ to maximize team productivity?

A: Many of our customers want to know how they can maximize
productivity through our patented office groupware innovations. The
answer is simple. First, click on the File menu, scroll down to
Increase Productivity, then…

The problem with such FAQs is that they are not, in a literal sense,
FAQs at all. No one ever called the tech support line and asked, “How
can we maximize productivity?” Rather, people asked highly specific
questions, such as “How can we change the calendaring system to send
reminders two days in advance instead of one?” and so on. But it's a
lot easier to make up imaginary Frequently Asked Questions than it is
to discover the real ones.

===== end =====

in other words, a *good* FAQ might be:

"how can i use the yocto prebuilt toolchains to save build time?"

a *bad* FAQ would be:

"Does the Yocto Project have a special governance model, or is it
managed as an open source project?"

the kicker is that that last question is, in fact, in the yocto FAQ,
along with a number of other questions that have never been asked by
anyone in the history of the planet. i chat about yocto with people
on a regular basis, and i can assure you, not a single one of them has
ever asked, "hey, rob, can you explain yocto's governance model?"

no, what they ask is, "hey, rob, how can i add a single package to
an existing target?" a question that, i should point out, is not
answered definitively in the existing docs *anywhere*.

I'm afraid you have fallen into the yocto trap of confusing the umbrella project with the buildsystem project under that umbrella. There's an easy way to find out, everytime you hear someone state 'yocto' you just ask:

'Do you mean "yocto" or do you mean "poky"?'.

The reaction to that can go a few ways and the follow up actions I recommend:

1) People don't get the question and/or don't know the difference between 'yocto' and 'poky'. Pretend you have a nosebleed and walk away, fast
2) People say "Right, I meant the buildsystem, not the umbrella project" or "No, I really meant 'yocto' as the umbrella project". Continue the conversation.
3) People say "Koen put you up to this, didn't he?". You're most likely talking to Dave or Saul, buy them lunch :)

regards,

Koen

Thanks all - I enjoyed the rant. The obvious point is that the FAQ needs attention. A good thing to do would be if you have a question that you would like included in a "good" FAQ, such as the one mentioned by Robert about how to add a single package, put the question up on this list or actually submit a patch to the list. As this little discussion thread noted, the FAQ was initially created when the project launched and I think much of it revolved around trying to answer the general "What the hell is Yocto anyway" question. I think we have moved into a "how do I do this" type of phase now and the FAQ should have more of those types of entries. That is not to say that questions about the Yocto Project in general should be deleted.

I will put some attention on the FAQ to try and inject a bit of value into it.

Thanks,
Scott

On Tue, 26 Jun 2012, Rifenbark, Scott M wrote:

Thanks all - I enjoyed the rant. The obvious point is that the FAQ
needs attention. A good thing to do would be if you have a question
that you would like included in a "good" FAQ, such as the one
mentioned by Robert about how to add a single package, put the
question up on this list or actually submit a patch to the list.
As this little discussion thread noted, the FAQ was initially
created when the project launched and I think much of it revolved
around trying to answer the general "What the hell is Yocto anyway"
question. I think we have moved into a "how do I do this" type of
phase now and the FAQ should have more of those types of entries.
That is not to say that questions about the Yocto Project in general
should be deleted.

I will put some attention on the FAQ to try and inject a bit of
value into it.

since the ubiquitous reaction to complaining about something is
always, "don't just whine, do something about it," i'm doing that.
i've started a personal yocto FAQ, based on questions either i've
asked myself, or colleagues or clients have asked me, and i'm posting
them here (obviously a work in progress, typed in over the last hour):

http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ

i'm collecting questions that clearly belong in a "how do i do X?"
FAQ and, even if i don't know the answer, i'm still going to add the
question to remind me to *find* the answer.

if you want to add a question and answer (or even just a question
because you *want* to know the answer), drop me a note -- that wiki is
not world-writable and never will be.

anyway, back to work ...

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On 06/26/2012 03:09 AM, Paul Eggleton wrote:

On Tuesday 26 June 2012 05:09:34 Robert P. J. Day wrote:

in other words, a *good* FAQ might be:

"how can i use the yocto prebuilt toolchains to save build time?"

a *bad* FAQ would be:

"Does the Yocto Project have a special governance model, or is it
managed as an open source project?"

the kicker is that that last question is, in fact, in the yocto FAQ,
along with a number of other questions that have never been asked by
anyone in the history of the planet. i chat about yocto with people
on a regular basis, and i can assure you, not a single one of them has
ever asked, "hey, rob, can you explain yocto's governance model?"

no, what they ask is, "hey, rob, how can i add a single package to
an existing target?" a question that, i should point out, is not
answered definitively in the existing docs *anywhere*.

You bring up a valid point, but I think it might be worth mentioning that the
current FAQ evolved from a much less technically-oriented version that was
produced when the project launched. At that time some people *were* asking the
kind of questions that you're deriding. I think there's still a section of the
*non-technical* audience who are interested in answers to those questions.

I suggested to Scott R previously that it might be worth having a project FAQ
(i.e., what is this project about, what is it intended to be used for etc.)
and a separate technical FAQ which answers the kind of questions you are
expecting and that we see often on the mailing list. I think one of the
reasons that hasn't been done is that we're hoping to introduce a Q&A function
on the website similar to StackOverflow, where everyone can participate but the
most appropriate answers bubble up to the top. As yet this has not been
implemented and I'm not sure when it will be, so it may still be worth looking
into a static technical FAQ on the wiki until it is.

Is "technical FAQ" == "How-Do-I pages" ?


--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Great! Thanks Robert.

On Tuesday 26 June 2012 08:46:45 Darren Hart wrote:

On 06/26/2012 03:09 AM, Paul Eggleton wrote:

I suggested to Scott R previously that it might be worth having a project
FAQ (i.e., what is this project about, what is it intended to be used for
etc.) and a separate technical FAQ which answers the kind of questions
you are expecting and that we see often on the mailing list. I think one
of the reasons that hasn't been done is that we're hoping to introduce a
Q&A function on the website similar to StackOverflow, where everyone can
participate but the most appropriate answers bubble up to the top. As yet
this has not been implemented and I'm not sure when it will be, so it may
still be worth looking into a static technical FAQ on the wiki until it
is.

Is "technical FAQ" == "How-Do-I pages" ?

Kind of, except most but not all FAQ questions really fit into "How do I...".

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On Tuesday 26 June 2012 11:45:50 Robert P. J. Day wrote:

since the ubiquitous reaction to complaining about something is
always, "don't just whine, do something about it," i'm doing that.
i've started a personal yocto FAQ, based on questions either i've
asked myself, or colleagues or clients have asked me, and i'm posting
them here (obviously a work in progress, typed in over the last hour):

http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ

i'm collecting questions that clearly belong in a "how do i do X?"
FAQ and, even if i don't know the answer, i'm still going to add the
question to remind me to *find* the answer.

Just looking at that page, a couple of items spring to mind:

1) Why are you pointing people to the prefile/postfile options in preference to
just putting the "common, personal configuration" in local.conf?

2) Your IMAGE_INSTALL_append example needs a leading space in the string or it
will almost certainly not work (or at least, it will only work when there's
already a trailing space in the value of IMAGE_INSTALL).

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On Tue, 26 Jun 2012, Paul Eggleton wrote:

On Tuesday 26 June 2012 11:45:50 Robert P. J. Day wrote:

since the ubiquitous reaction to complaining about something is
always, "don't just whine, do something about it," i'm doing that.
i've started a personal yocto FAQ, based on questions either i've
asked myself, or colleagues or clients have asked me, and i'm posting
them here (obviously a work in progress, typed in over the last hour):

http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ

i'm collecting questions that clearly belong in a "how do i do X?"
FAQ and, even if i don't know the answer, i'm still going to add the
question to remind me to *find* the answer.

Just looking at that page, a couple of items spring to mind:

1) Why are you pointing people to the prefile/postfile options in preference to
just putting the "common, personal configuration" in local.conf?

i thought that was the technique for centralizing personal config
preferences that you *didn't* want to manually copy into every
local.conf file you created. if you add that personal content into
each local.conf, then of course you don't need those options.

2) Your IMAGE_INSTALL_append example needs a leading space in the string or it
will almost certainly not work (or at least, it will only work when there's
already a trailing space in the value of IMAGE_INSTALL).

whoops, quite so.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On Tuesday 26 June 2012 12:26:28 Robert P. J. Day wrote:

i thought that was the technique for centralizing personal config
preferences that you *didn't* want to manually copy into every
local.conf file you created. if you add that personal content into
each local.conf, then of course you don't need those options.

I guess it depends on what you mean by "personal content". Certain settings
are really part of distro policy and if you're finding that you're setting them
all the time for all of the builds that you're doing, it would make more sense
to create a distro layer that sets them - then it's simply a matter of
ensuring that layer is added to your bblayers.conf and you set DISTRO as
appropriate.

AFAIK the command line options in question were added to allow frontends to
inject configuration into bitbake rather than something the user would normally
use directly.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On 26/06/12 17:06, Paul Eggleton wrote:

On Tuesday 26 June 2012 08:46:45 Darren Hart wrote:

On 06/26/2012 03:09 AM, Paul Eggleton wrote:

I suggested to Scott R previously that it might be worth having a project
FAQ (i.e., what is this project about, what is it intended to be used for
etc.) and a separate technical FAQ which answers the kind of questions
you are expecting and that we see often on the mailing list. I think one
of the reasons that hasn't been done is that we're hoping to introduce a
Q&A function on the website similar to StackOverflow, where everyone can
participate but the most appropriate answers bubble up to the top. As yet
this has not been implemented and I'm not sure when it will be, so it may
still be worth looking into a static technical FAQ on the wiki until it
is.

Is "technical FAQ" == "How-Do-I pages" ?

Kind of, except most but not all FAQ questions really fit into "How do I...".

Kooen's cheeky point is worth keeping in mind though; the Yocto naming
semantics is not very helpful ;-) Specifically most of the questions
being asked on the Yocto list are about Poky, not Yocto, followed by
questions about meta-yocto, not Yocto-project. Many of the questions
being asked on the list are readily answered by googling for 'Poky
Manual', but clearly very few people understand the Yocto project
semantics enough to do this ...

Tomas

Cheers,
Paul

On Tue, 26 Jun 2012, Paul Eggleton wrote:

On Tuesday 26 June 2012 12:26:28 Robert P. J. Day wrote:

i thought that was the technique for centralizing personal config
preferences that you *didn't* want to manually copy into every
local.conf file you created. if you add that personal content into
each local.conf, then of course you don't need those options.

I guess it depends on what you mean by "personal content". Certain
settings are really part of distro policy and if you're finding that
you're setting them all the time for all of the builds that you're
doing, it would make more sense to create a distro layer that sets
them - then it's simply a matter of ensuring that layer is added to
your bblayers.conf and you set DISTRO as appropriate.

AFAIK the command line options in question were added to allow
frontends to inject configuration into bitbake rather than something
the user would normally use directly.

ok, that makes sense. but would it also make sense for bitbake to
perhaps support another option that *does* allow personal content to,
say, be effectively appended to one's local.conf. for instance, every
single local.conf i create immediately gets this added to the end:

SOURCE_MIRROR_URL ?= "file:///home/rpjday/dl/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
# BB_NO_NETWORK = "1"

is there a simpler way to do that?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On Tue, 26 Jun 2012, Tomas Frydrych wrote:

Kooen's cheeky point is worth keeping in mind though; the Yocto
naming semantics is not very helpful ;-) Specifically most of the
questions being asked on the Yocto list are about Poky, not Yocto,
followed by questions about meta-yocto, not Yocto-project. Many of
the questions being asked on the list are readily answered by
googling for 'Poky Manual', but clearly very few people understand
the Yocto project semantics enough to do this ...

and if you want major industry players to take yocto seriously, the
last thing you want to do is answer their heartfelt pleas for
assistance with, "i'm sorry, that's technically not a yocto question,
you should try another mailing list."

even if you're technically correct, that sort of conversation is not
going to end well.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On Tuesday 26 June 2012 12:51:15 Robert P. J. Day wrote:

On Tue, 26 Jun 2012, Paul Eggleton wrote:

On Tuesday 26 June 2012 12:26:28 Robert P. J. Day wrote:

i thought that was the technique for centralizing personal config

preferences that you *didn't* want to manually copy into every
local.conf file you created. if you add that personal content into
each local.conf, then of course you don't need those options.

I guess it depends on what you mean by "personal content". Certain
settings are really part of distro policy and if you're finding that
you're setting them all the time for all of the builds that you're
doing, it would make more sense to create a distro layer that sets
them - then it's simply a matter of ensuring that layer is added to
your bblayers.conf and you set DISTRO as appropriate.

AFAIK the command line options in question were added to allow
frontends to inject configuration into bitbake rather than something
the user would normally use directly.

ok, that makes sense. but would it also make sense for bitbake to
perhaps support another option that *does* allow personal content to,
say, be effectively appended to one's local.conf. for instance, every
single local.conf i create immediately gets this added to the end:

SOURCE_MIRROR_URL ?= "file:///home/rpjday/dl/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
# BB_NO_NETWORK = "1"

OK, looking at the settings you've listed, I think these are the kinds of
things that site.conf was invented for - stuff that is specific not to the
builds you are doing but to the host machine / site. You can simply put these
settings in a file called site.conf next to local.conf and they'll be read from
there; for new build directories you can just copy it in or symlink it from
some common location.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On Tue, 26 Jun 2012, Paul Eggleton wrote:

On Tuesday 26 June 2012 12:51:15 Robert P. J. Day wrote:

On Tue, 26 Jun 2012, Paul Eggleton wrote:

On Tuesday 26 June 2012 12:26:28 Robert P. J. Day wrote:

i thought that was the technique for centralizing personal config

preferences that you *didn't* want to manually copy into every
local.conf file you created. if you add that personal content into
each local.conf, then of course you don't need those options.

I guess it depends on what you mean by "personal content". Certain
settings are really part of distro policy and if you're finding that
you're setting them all the time for all of the builds that you're
doing, it would make more sense to create a distro layer that sets
them - then it's simply a matter of ensuring that layer is added to
your bblayers.conf and you set DISTRO as appropriate.

AFAIK the command line options in question were added to allow
frontends to inject configuration into bitbake rather than something
the user would normally use directly.

ok, that makes sense. but would it also make sense for bitbake to
perhaps support another option that *does* allow personal content to,
say, be effectively appended to one's local.conf. for instance, every
single local.conf i create immediately gets this added to the end:

SOURCE_MIRROR_URL ?= "file:///home/rpjday/dl/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
# BB_NO_NETWORK = "1"

OK, looking at the settings you've listed, I think these are the
kinds of things that site.conf was invented for - stuff that is
specific not to the builds you are doing but to the host machine /
site. You can simply put these settings in a file called site.conf
next to local.conf and they'll be read from there; for new build
directories you can just copy it in or symlink it from some common
location.

that still requires just a touch of user intervention. no totally
automatic way to do that, then? it's at least an improvement over
manual copying, thanks.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

So this situation might lend itself to a nice FAQ question.... Something like "How do I isolate site and machine specific information during a build?" And the solution can tell them how to use a site.conf file.

Scott