-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Russ,
Thank you for your intelligent reply. Most of what you state is on the mark 100%. Please see my comments below: Message replied to: Date: Tue, 03 Jul 2012 19:04:55 -0700 From: Russ Allbery <r...@debian.org> To: jlma...@gmail.com Cc: debian-devel@lists.debian.org Subject: Re: Concerns and Challenges of Squeeze and Ongoing Elements > "John L. Males" <jlma...@gmail.com> writes: > > > Etch and Lenny were were generally positive experiences in > > terms of stability with the exception of apt-get and > > apt-get related cousins. As of Squeeze I have experienced > > a number of problems that include, but limited to: > > Hi John, > > I'm sorry that you've had so many troubles with squeeze. I > wish that you'd had a better experience. Thanks. I wish my experience was better. > > The difficulty with a comprehensive inventory such as you > posted, I fear, is that it's almost guaranteed, from its > structure, to result in no effective improvement whatsoever. My intent was not to report specific issues or have them resolved. Some points I made later provide some insight to my expectation that no improvement was expected. It was meant to give a sense of the challenges even for a very experience technical person using Linux at this level for over 10 years. > To understand why, one has to understand a bit more about how > the Debian project is structured. (You may already know much > of this... but I'm guessing that given your message you may > not have connected those pieces.) My references to the volunteer nature of the Debian project also implied more. I believe I had all the pieces connected before I sent my eMail note and I know applies not just to Debian. > > Debian is primarily an assemblage of components that are all > maintained, and tested, largely independently by the package > maintainers. There is some coordinated distribution-wide > testing, but those efforts quickly result in bugs filed > against individual packages. Debian tries hard to keep its > components loosely coupled since otherwise creating the > distribution with the type of resources Debian has available > would be simply impossible. Understood and I was aware of this connected piece prior. > > The sort of message that you've written is the kind of > message that one would send to a commercial software vendor, > where it might be triaged by a technical sales manager and > possibly taken apart by the QA department to see what further > testing they could do and what issues they could resolve. Correct, but generally nothing happens. One reason is "nobody" else is having the issue(s), or they do not feel it is cost effective. As an FYI I happen to know alot about this aspect having worked in this side of things as 2nd/3rd Level Support between customer and engineering or I was the Senior QA person. > Debian does not have any of those people. There is no one > person or set of person "in charge" of the overall quality of > the distribution who can distribute out tasks, nor are there > teams of people who can investigate comprehensive reports. Understood and a connected piece I was aware of prior. My eMail is in part highlighting that this may be an area that may be people could be found to do. It was not the intent, just when one has a problem sometimes it is worth looking at possible solutions and if a solution is possible. I am not suggesting your above point is the solution. It is a starting point for sure, but again I repeat I am not saying that is or is not the solution. In my opinion there is actually a larger discussion. > There are only individual maintainers and maintenance teams > who manage specific packages, with some project-wide > coordination (and most of your issues do not sound like > coordination issues, but rather issues with specific pieces > of software). The connected piece you noted I was aware of prior. Actually the issues, though sound specific pieces of software, at first glance are in fact project wide caused. I know this from my experience over the years professionally and with OSS. > > Therefore, this sort of long inventory, while providing an > outlet for the frustration of encountering multiple bugs, is > basically going to disappear without a trace (apart from, I > suspect, some defensiveness). Insofar as those bugs can be I am not like most people, so it frustration of the net result of regression I have experienced ad noted is in terms of facts and not emotion. As an FYI anyone that knows me knows that I am a factual, rational person and rarely emotional. The length, time and effort I put into the eMail is because I stick to facts. If I was emotional I would have written a far shorter eMail. So this is about facts and it is not uncommon for most to read emotion in this who do not know me. Though I do use some emotion, like "sadly" and such those are used more to try to convey some sense others who would use emotional words and not me being emotional per se. So in essence the "fustration" you observe in my eMail is a frustration of facts and collective objectives for OSS, QA and SDLC. > tracked down and fixed, it will be through being separately > filed against the individual relevant packages by people who > can reproduce them. - From my professional experience I can tell you there have been problems where it is clear the customer has a problem, but engineering or other peers have not been able to reproduce the problem. This includes a problem that was crippling once every three months and a different problem of a different customer that nobody, not even the engineering teams working the problem from day one could reproduce for the problem that was several times a day for over 18 months. In the latter case our teams I was a part of were bypassed for some unique sales team reasons I cannot disclose, but made no sense I can assure you. What I can say is in both cases to shock of engineering, field specialists and managers I was able to reproduce both issues in less than an hour once I was given the opportunity to do so. The assumption was that if engineering with the source code and developers of the source code and hardware designs could not figure the issue out then nobody can. The point I am making here is not one to pat myself on the back. The point is that it not fair to assume who is capable of duplicating the problem. I became a called upon resource by engineering and field to problems that were a challenge and connected to external technology never seen before that often played a role to the problem that nobody could duplicate. In a few cases it was near impossible to articulate how to duplicate a few unique problems to engineering. So instead debugging information from the embedded device was collected when the problem occurred and that enabled engineering to isolate the problem, make a fix and then I test the fix. As fate had it that was enough to enable engineering o fix the problem the first time in those two instances. This is a team effort. This means customers have serious problems. Engineering/Developers can only fix problems they can see. I had a unique ability to be able to duplicate serious problems nobody else could. The point here is the assumption of who can reproduce a problem is an assumption all to often incorrectly made. I am not saying with respect to the eMail I sent initially I am the "one". I am saying it is a collaborative effort. I can tell you from experience if I know how to duplicate these problems that generally volunteers with the workload as you indicate is just to much verses time volunteers have to spend trying to duplicate issues. In my experience generally volunteers do not want to be advised how a problem is duplicated when it is a challenging problem. If the problem can be duplicated using a small amount of time and effort there will be no issue from volunteers. I can tell you the issues I am referring to here require alot of time and effort on my part as well as volunteers. I can tell you from experience volunteers push back and doing so means I have to spend more time to make it easier for them, but the fact is it results in something volunteers do not even want to tackle as they do not feel the level of effort and detail is required without trying first and finding they can in fact they can recreate the problem in their own way or reply that my approach is invalid for a variety of reasons. > > Debian simply doesn't work like most software, due to both > the breadth of the distribution and the volunteer nature of > the community. This sometimes means that bugs go unfixed > because no one has time to dive into them far enough to > figure out where the root problem lies. Bugs will definitely > go unfixed if no one has time to even get as far as reporting > them against a relevant package. Understood and a connected piece I was aware of prior. My comments immediately above apply to your comments here as well. There are solutions, but this requires a different approach by the OSS community as a whole. That is a very different discussion and one that is broader than a specific distribution and not in scope with respect to my initial eMail, nor this eMail reply. > > It's always worth bearing in mind that if something seems > completely unusable, and yet is used by many other people who > are not constantly complaining about it, there is probably > something specific to how you're using it that is causing you > to encounter problems that other people are not having. For Absolutely correct. That said my comments a few below also apply here. > example, I'm using Debian squeeze across several hundred > servers and never encounter kernel panics. Perhaps my > hardware is different, perhaps my usage is different... it's > hard to tell. But a plea that starts from, effectively, the > position of "this is unusable" is not actually going to > produce the urgency that you seem to desire, since for the I do not believe I use any word like urgency. I did use "this is unusable". > rest of us it obviously *is* usable. Ironically, it instead > reduces the credibility of the message and makes it even more > likely people will ignore it, even though you have probably > encountered, due to your specific work load, real bugs that > really do need to be fixed and which are serious for you. Correct. Let me add this perspective below. There are many, if not hundreds of bugs fixed in Debian release to release, including security fixes. This holds true for any large software program. It is a well know fact most users, over 99% generally have not even encountered one of the bugs that is now fixed in the new version or release of the software. Yet these were genuine bugs reported by one or a few users likely in the 0.0001% of people using the software. That means for practical purposes most people never encountered the problem. So the several hundred fixes though listed as issues is has no impact to them. There are many technical people who will not even apply updates despite the long list of bugs, some very serious, fixed in new release as they work on the premise if it is not broke do not fix it. The reason is these same techs have fallen victim to updating as some of the fixes they feel are important to be proactive only to be caught blind sighted to the working system now breaks. I will skip the reasons this happens, but the point here is many will not apply fixes even with a long list of fixes including ones that are very important fixes. On the flip side the 0.0001% will encounter bugs that they reported and were is *not* useable. So while for most the soft is useable, it is not for these 0.0001% people. An if there is not fix then those people will not use that piece of the software. I can tell you for a fact, and others have seen this, I am not the use 20% of functionality 80% of the time type. I am more like a use 45% of functionality 90% of the time type. So yes I will tend to experience things most people do not. Yes "due to your specific work load, real bugs that really do need to be fixed and which are serious for you." is correct. As to the "Ironically, it instead reduces the credibility of the message and makes it even more likely people will ignore it" is actually the basic root issues of issues, be it software, hardware, cars, electronics, etc. This is an assumption that is actually an assumption and not a fact. What is also assumed is that others are not having similar problems. It is a well known fact that for about 1% report a problem and the rest do not. I am proof of that for the Etch and Lenny issues I found and fixed on my own and the many apt-get and related cousin issues I have never reported that are very serious. The simple fact is it is assumed everyone is using the same functionality and they are not. Most do not use the 20% functionality 80% of the time I believe. That by definition leaves alot of functionality not used and likely not tested as OSS testing is mostly a result of what users use which creates the well nobody else is experiencing the issue. Add in only 1 in 100 will report the issue one can see how many reported problems, even serious ones, most users never experience nor understand the nature of problem for software update they apply to their systems. > > If it's less effort for you to switch to another distribution > than to try to track down the origins of the problems you > encountered and report them to the specific packages involved > (ideally with some hint as to why the problem is affecting > you more severely than other users), I can certainly > understand that choice. But Debian is also unlike commercial It is less effort based on my prior experience, the challenges of the volunteer nature of the process, assumptions people make what it really takes to duplicate such issues, and technical hardware/server resources available to those that work on problems. I think hits like DoS to a client workstation, kernel opps are the type of hints the problem is more severe. Also the hint that when one uses the source from Kernel.org the kernel opps never happen again on the system for which the only change was the kernel and where the kernel was sourced from. > software in that the project is not driven by market share, > and it's unlikely that anyone will play the role of technical > sales and pick up your list of complaints and shephard them > through the project for you, even if the alternative is for > you to switch to another distribution. (Among other things, > that's a lot of hard work, and none of us get paid to do that > sort of work for Debian.) Understood and a connected piece I was aware of prior. As an aside I believe "the project is not driven by market share", "(Among other things, that's a lot of hard work", and "none of us get paid to do that sort of work" is one reason OSS is is unable to make a bigger impact for a variety of reasons. This is a much larger discussion and not the scope of my original eMail, but my eMail and your response indirectly does touch on this larger scope in a very small way indirectly. > > So... Debian is what it is, and in this particular respect I > don't think Debian is going to change. If that makes it a > poor match for your needs, that does make me sad. I like > Debian a lot, and I like having more people use it because > that makes Debian better. But it sounds like you've had a I do not know if Debian will change, but maybe if more people will willing to speak up, rise to the challenge, it would be wonderful. I liked Etch and Lenny very much. By no means perfect, but at least one could accomplish the key aspects of keeping up to date, rebuilding from source even if it was far more time consuming and fret at times with package bugs that sometimes drove one nuts to resolve. > miserable experience, and I'm sympathetic to not having the > time to pursue what sounds like an overwhelming number of > bugs for your situation. > > I felt like someone should tell you that no one is likely to > have the reaction to your message that you wish, particularly > since you clearly put a lot of time and energy into it. I am not sure what you mean my reaction. Your reply was a reaction and a intelligent and practical reaction. KI did place alot of time and energy to the initial eMail and now this reply. With respect to this reply is was to hopefully enlighten in in broader sense and as apply to the the eMail and your reply. Again Russ, thanks for your intelligent reply. I am certainly not upset with your reply or level setting you articulated. I trust you find my reply in kind. > > -- > Russ Allbery (r...@debian.org) > <http://www.eyrie.org/~eagle/> Regards, John L. Males Toronto, Ontario Canada 04 July 2012 00:10 <mailto:jlma...@gmail.com> ============================================================== 2012-07-03 22:20:30.788247314-0400-EDT 3 Jul 22:20:30 ntpdate[14951]: ntpdate 4.2.6p2@1.2194-o Sun Oct 17 13:35:14 UTC 2010 (1) 3 Jul 22:20:44 ntpdate[14956]: step time server 72.38.129.202 offset 0.000505 sec Linux 3.3.4-kernel.org-jlm-010-amd64 #1 SMP PREEMPT Thu May 3 17:02:56 EDT 2012 Modified Debian GNU/Linux 6.0.3 (squeeze) Planning, Upgrade, Modifications from Highly modified Debian 4.x Etch -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk/zwioACgkQ+V/XUtB6aBDJ7QCdGCd3m54pU3fsahxfROkeNPF/ DCUAn23aO2H3E8kXWL+kEL5UQebqh20G =qC8B -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120704001018.7a728280.jlma...@gmail.com
