Michael,
I would like to explain the unfortunate circumstances of manuals being out of sync. I hope my
explanation below as to why things are the way they are is satisfactory. As to my own conduct
towards you, I admit I was a bit brusque and presumptive, and do offer apology. While it may be
somewhat of an occupational hazard, I do not mean to excuse it, but I do wish to clear up the
intention behind my remarks, which was certainly not to belittle.
Unfortunately, that would take considerably more work than you might imagine. The manual authors and
On 09/20/2012 04:27 PM, Michael . wrote:
> As for practical suggestions I'd suggest you or someone else posts a manual on the live site, that
> is actually accurate for the versions of Live Build that are available in each dist. If the manual
> was accurate in the first instance I wouldn't have come onto the list to ask a question.
translators make commits into git which, in turn, flow into unstable and then to testing. We don't
write documentation directly for testing. By the time it reaches testing, it may in fact be ahead of
live-build or behind, as we have no way to predict when the migrations will be complete for each
version. The end result is some slight out-of-sync-ness of manual version with live-build version,
not to mention also live-boot, live-config and friends. So you see, keeping the doc in sync during
the turbulent pre-release period is a non-trivial problem to solve. You will also see, looking at
http://live.debian.net, that we mark the versions of the documentation we make available online as
being for oldstable, stable and unstable. This is no accident. It cannot easily be any other way.
The good news is that by the time stable releases, we work towards complete synchronization of the
documentation with the software that ends up in the stable release. In the meantime, as a user of
testing, you need to be aware of the situation and work around it. Often the simplest thing to do is
to install live-build from unstable, and mix in live-boot and live-config from unstable in your test
builds (as live-manual explains how to do with APT pinning).
Maybe this is simply a matter of culture/language clash? In my lexicon, which is heavily laced with
> Another practical suggestion. You may be sorry about the "superior tone" but your choice of words,
> even in this email with the word "dance", says to me you are still using the "superior tone". Dance
> is in no way a technical term in IT circles, if you want your users to use technical terms then I
> personally would appreciate it if you would do likewise.
terms commonly used in informal speech in technical circles, "dance" is by no means a pejorative. If
anything, it is a somewhat whimsical way to refer to any seemingly complex and possibly not
necessary (or at least something we *wish* were not necessary) set of steps to achieve an intended
result. If I failed to see the point of the steps you took, making it appear to me as a "dance",
please do not take that as an insult. It speaks more of my own ignorance, in that case, than a
deliberate, mean-spirited and/or arrogant stance. I am certainly not beyond taking correction when
I've misunderstood.
Let's clear up the intention behind those remarks. Because you did not state any theory about
potential corruption (files you had removed yourself? your disk going bad? brokenness of one of our
maintainer scripts?) nor any direct evidence of corruption (mismatched 'debsums' to name one) nor
did you include any output, preferring instead to very briefly summarize the actions you took, this
gave the *appearance* of you trying random things with unclear motivation as to your line of
reasoning. In the private email you sent, you divulged further details about the systematic line of
inquiry you were taking. That was unclear from your public posts. If there is anything left her for
me to beg apology for, it is for having assumed the lack of a plan (that was not in evidence at the
time) instead of assuming the reverse and encouraging you to explain your reasoning. So for this, I
am sorry. After years of handling user support sessions with tens of thousands of mis-steps by users
in debugging their problems, one has a tendency to develop a bit of brusqueness at times, in an
eagerness to come quickly to the point and help solve the problem systematically. I do see how that
could be confused for taking a superior tone and will endeavour to check myself in future if I find
I am straying in that direction.
Chals is indeed a valuable asset to our team. I daily appreciate his contributions and probably do
> Chals was a great help filling in the blanks of the manual and offering other suggestions, I
> appreciate his assistance.
not tell him enough how much he improves the quality of support for Debian Live in general.
Very well. We'll end it here, then. I'm glad you got things sorted out.
> I'm not interested in discussing this further as the issue I asked the
> question about has been resolved.
Peace,
Ben