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.
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. Unfortunately, that would take considerably more work than you might imagine. The manual authors and 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). > 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. Maybe this is simply a matter of culture/language clash? In my lexicon, which is heavily laced with 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 was a great help filling in the blanks of the manual and offering other > suggestions, I > appreciate his assistance. Chals is indeed a valuable asset to our team. I daily appreciate his contributions and probably do not tell him enough how much he improves the quality of support for Debian Live in general. > I'm not interested in discussing this further as the issue I asked the > question about has been resolved. Very well. We'll end it here, then. I'm glad you got things sorted out. Peace, Ben -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505c4953.6060...@sanctuary.nslug.ns.ca
