Re[02]: Concerns and Challenges of Squeeze and Ongoing Elements
-----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 <rra@debian.org>
To: jlmales@gmail.com
Cc: debian-devel@lists.debian.org
Subject: Re: Concerns and Challenges of Squeeze and Ongoing
Elements
> "John L. Males" <jlmales@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 (rra@debian.org)
> <http://www.eyrie.org/~eagle/>
Regards,
John L. Males
Toronto, Ontario
Canada
04 July 2012 00:10
<mailto:jlmales@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-----
Reply to: