Concerns and Challenges of Squeeze and Ongoing Elements
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ladies and Gentlemen,

I have been using Debian as my primary distribution for the
last 4 years. I have been using Linux as my only OS since
1999. My decision to move to Debian included the many
derivatives of Debian I may use for various purposes, the
concept of apt-get, and the different hardware platforms
supported. I have been trying to use Squeeze since December
2011, but unlike Etch and Lenny to date I have not been able to
do so due to a variety of Squeeze issues.

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:

* LiveCDs that do not work properly with some VM software, but
others just fine at the desktop GUI level

* Debian Squeeze Linux kernels that opps so many times it was
not funny, Debian Linux kernel sources that had several issues I
cannot remember them all both in terms of ability to compile,
major functionality differences outright crashes. I was always
able to use Etch and Lenny Linux kernels in main or backports
with confidence. With Squeeze it was a disaster right from the
base virgin install in every respect. When I switched from the
Debian kernels to the Kernel.org Linux kernels all the Debian
Linux kernel problems disappeared and not one kernel opps since
using various Kernel.org 3.2.x and 3.3.x versions as released.
I have lots of kernel configuring, compiling and testing
experience since 1999. One other distribution which I will not
name also had a similar disaster record with their distribution
specific Linux kernels and was how I got started in learning
how to configure and compile kernels from Kernel.org.

* Major and serious problems compiling packages from source.
What is even worse is Debian developers seriously challenging
why I would compile from source, i.e. security fixes,
kernels, etc. Aside from some odd bumps in compiling from
source with Etch and Lenny there were no major problems.
However I cannot even compile many of the most basic and key
elements of Squeeze due to a number of problems related to
the package or more commonly the design of the packages in
Squeeze. So you have a context of the extent of compiling
from source with Etch and Lenny it was almost all packages
were recompiled for a variety of reasons - security updates,
backports, et al. Suffice to say aside from Debian I also
used to rebuild from source with RPM based systems prior to
my using Debian as my primary distribution.

* Major problems with one very primary and key software
package that had on many occasions, including the latest
security release, such that the entire system is brought to its
knees in what would clearly be classified a system DNS that
will last for hours and one cannot access the system as a
result. I suspect, but have not confirmed that this many be a
double edge problem in that the very primary and key software
package may also be playing on top of a Linux kernel issue
that I have some extensive testing knowledge of.

* apt-get and its related cousins that in fact cause more
problems, want to remove key user applications that clearly are
not related to the package the user wishes to remove, or will
want to revert important changes the user has made to customize
their system in normal user ways causing the user to constantly
having to spend alot of time redoing the configuration they set
up and choose each time an apt-get is run. This has been a
problem with Etch, Lenny and Squeeze, progressively getting
much worse. The net result is giving up trying to maintain
the normal user customizations or spending alot of time and
effort with creative workarounds.

* apt-get and related cousins become broken when a user
configures the system in ways a user is allowed to do so.
Again a problem with Etch, Lenny and Squeeze. Again the net
result is not being able to use apt-get and related cousins and
spending alot of time doing such manually which defeats the
purpose of apt-get.

* Some packages seem to consistently have the same problems for
many version/security releases and/or releases (Etch to Lenny
to Squeeze) despite Debian bug logs indicating the issue was
fixed, in some cases several times. In some cases the same
problem would be reported by someone for the same package that
was supposed to have the problem fixed and was not. I never
reported or added my experience to confirm the issue existed
even after I researched using other resources and skills to fix
these Debian packages so they would compile and/or install.
Frankly if the same problem was appearing over a few years and
several versions of the Debian package for these different
software packages then I saw little point to spending my time
spinning on the issue and not see it resolved as already stated
was resolved when it would take me about a hour or few of
research, fixing, repackaging, compiling and/or installing the
package myself.

There are more issues, a few I tried to report over the years,
many I did not as I was almost always met with a challenge of
those that felt my concerns were invalid. Once someone else
I never knew prior or after made a comment that my concerns were
very valid and made excellent points why. Even then the
person(s) responsible were defiant. They expected me to spend
alot of time testing something they already knew was an issue
for Debian, but not for any Debian derivative of at least the
past 5 years. So I simply did not use Debian for the solution
I was working on. I used another Linux distribution for the
matter at hand that worked.

As a result it now seems I have to sadly spend time researching
and testing an alternative OSS and/or Linux based distribution
due to the serious and addition issues that Squeeze has
introduced. It also means I have to again migrate my system,
configurations and customizations a user is allowed to make to
their system. This is not a small effort and one that takes
careful effort that include backups, a few weeks of effort over
and above trying out other distributions. In essence I have
lost confidence in Debian as a distribution. I fully
understand OOS, people volunteering their time, et al for a
distribution. The point is Squeeze has made a number of
backward steps that are Debian specific including decision that
are temporary and not fully thought through in key areas of
Debian specific scope as opposed to the OOS. A few examples
have already been noted in the points above. I tried my best
to find solutions to the issues, and yes I did not report many,
because experience has been it is yet another layer of
challenges that my personal time like the Debian volunteers
have limited time is also limited, but at same time seems to
amplify such that much more limited time, not less or efficient
time is made of everyone's limited time.

I hope at some point Debian can restore the stability of Etch
and Lenny in future releases and bring more coherence to the
Debian specific elements of the Debian distribution. If that
happens I would be very happy to give serious consideration to
Debian as my distribution again. As it stands now I cannot
recommend Debian Squeeze to others.


Regards,

John L. Males
Toronto, Ontario
Canada
03 July 2012 20:50
<mailto:jlmales@gmail.com>


================================================== ============
2012-07-03 19:38:59.935336752-0400-EDT

3 Jul 19:38:59 ntpdate[14261]: ntpdate 4.2.6p2@1.2194-o Sun
Oct 17 13:35:14 UTC 2010 (1)

3 Jul 19:39:57 ntpdate[14266]: step time server 199.212.17.35
offset -0.004486 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/zk0wACgkQ+V/XUtB6aBCS/ACfcwtpS6XSYMaPRWf8nm8x1csA
WusAn2mCxbR5geKOkVB9+X4wRF8ONfT8
=cLyr
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120703205020.c90d977f.jlmales@gmail.com">http://lists.debian.org/20120703205020.c90d977f.jlmales@gmail.com

Concerns and Challenges of Squeeze and Ongoing Elements
 

Quoting John L. Males (jlmales@gmail.com):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ladies and Gentlemen,

I hope that everybody will be Wise Enough to not feed the troll. But,
just in case: please don't feed the troll.

Concerns and Challenges of Squeeze and Ongoing Elements
 

Le Tue, Jul 03, 2012 at 07:09:44PM -0600, Christian PERRIER a écrit :
> Quoting John L. Males (jlmales@gmail.com):
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Ladies and Gentlemen,
>
> I hope that everybody will be Wise Enough to not feed the troll. But,
> just in case: please don't feed the troll.

Hi Christian,

I do not think there is much trolling. We need to discuss issues openly. On
servers I will upgrade to Wheezy, but on desktops, I am not sure. While the
GNOME team's work is outstanding, and while I like GNOME 3 and find it
promising, GNOME 3.4 is simply still lacking many simple features, such as
remembering some configuration changes and window positions, or giving by
default a configuration interface that allows to set the focus to follow the
mouse, etc., not to mention that I can not switch between French and Japanese
without losing the compose key and the dead keys. This will probably come back
with later versions, and I think I will wait for them and upgrade from Squeeze
to Testing at some time.

I also had some strange update problems with Iceweasel (where it is hard to
type in the title bar without having some letters randomly removed), and I
would like to emphasize that one of the reasons I have not even reported a bug
is precisely because I had the feeling that discussing such issues is unwelcome
unless one is able to dedicate a lot of time in solving the problem, and that on the
other hand, merely reporting a bug is not enough to solve a problem (such as having
GNOME3's tracker freezing my Desktop each time I start my computer #612242).

As long as people do not repeat themselves and push other people out of the
discussion by sending many emails a day, I do not think it is trolling to
discuss problematic issues. Upgrading to Wheey made my Desktop much less
usable than before. I promise to not send any other message in this thread.

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120704013545.GB26529@falafel.plessy.net">http://lists.debian.org/20120704013545.GB26529@falafel.plessy.net

Concerns and Challenges of Squeeze and Ongoing Elements
 

Hallo Charles,

am Wed, Jul 04, 2012 at 10:35:45AM +0900 hast du folgendes geschrieben:
> I do not think there is much trolling.

it's a whole lot of handwaving which doesn't actually help anyone.

Sadly so.

Kind regards
Philipp Kern

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.

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. 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.)

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.

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.
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. 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).

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 tracked down and fixed, it will be through being
separately filed against the individual relevant packages by people who
can reproduce them.

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.

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 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 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.

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 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.)

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
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.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pq8cjn7c.fsf@windlord.stanford.edu">http://lists.debian.org/87pq8cjn7c.fsf@windlord.stanford.edu

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-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120704001018.7a728280.jlmales@gmail.com">http://lists.debian.org/20120704001018.7a728280.jlmales@gmail.com

Concerns and Challenges of Squeeze and Ongoing Elements
 

On Tue, Jul 03, 2012 at 08:50:20PM -0400, John L. Males wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ladies and Gentlemen,

I replied to John in detail via a private e-mail. Summary : I suggested John
to report every problem via bug reports.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120704051942.GB6057@master.debian.org">http://lists.debian.org/20120704051942.GB6057@master.debian.org

Concerns and Challenges of Squeeze and Ongoing Elements
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04.07.2012 07:10, John L. Males wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

John, this is a little offtopic, but could you provide link or
keyserver where we can find your public PGP key. It doesn't seem to be
on pool.sks-keyservers.net, which I use and seems to be one of the most
popular keyservers (or keyserver pools).

- --
Mika Suomalainen

NOTICE! I am on mobile broadband with very limited time, so I cannot
read emails very much.
The best time to contact me is probably weekends when I have better
connectivity with good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Homepage: http://mkaysi.github.com/
Comment: gpg --keyserver pool.sks-keyservers.net --recv-keys 82A46728
Comment: Public key: http://mkaysi.github.com/PGP/key.txt
Comment: Fingerprint = 24BC 1573 B8EE D666 D10A AA65 4DB5 3CFE 82A4 6728
Comment: Why do I (clear)sign emails? http://git.io/6FLzWg
Comment: Please send plaintext instead of HTML. http://git.io/TAc0cg
Comment: Please don't toppost. http://git.io/7-VB3g
Comment: Charset of this message should be UTF-8.
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP8/ITAAoJEE21PP6CpGcoqrUQAJ8r4nQqjN+4iFDyyp2RtGu7
YBx6SPjcsTgagloST0YBA0lCDxsPX+he7GVGe6dU9s29koqYCR lvbc/xA+On7WW7
NrllLSJ42cSLA5XKAEPAY6dR9UbOm6B8XliS1sW12H9ozBoHb/+KYjpfpLxgrORj
sN39r2b5HAxR0crh690aS3pwF8Y5G6Nku4KAmnsqE8e2+OkW84 bwWubaeW8Rba/V
Tseol5pp6ue2ygb0n0DFJmiHQKeicdbQ94ituJTZOsg7JuGe6i F7k5lHZ6LNwthd
EUnPGV3KtN6CIOci6gzAGKI9tfbgpN0CIsPfq/KHliEFyHYMgPzdi7IbxPOZTBj+
sizUfVjPzdimUHBULDBkmvCCXgU/CzOTqlGrEM6tg/wT0u916eXZqhwaT+Ia2jO4
W2jf6m4UijGBBssjBn3hZDQFxf9YtMv9uHnfx1LNnLIDfRsdpF lbY6nUlCvwoz/p
VjYzWWzCJBMknCg0bPDwsPj3S5OOlehGYC0479fF8/Z9SNqzLKGdUST72EdvJlJ4
4R7rE/paU+uHxqOOibH7G6lM/iH63cMLK9E4ajrcig+7PI/FnACvCnJEjIGk27YL
4MUZiv2cka8h0324pRtzrcn1/n5SFzgsnqJXa4D98CMdH11gURYstVmPfGvfiC0P
8V5Hu/KYeIOgCyJZMcXJ
=NZul
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FF3F215.5030206@hotmail.com">http://lists.debian.org/4FF3F215.5030206@hotmail.com

Concerns and Challenges of Squeeze and Ongoing Elements
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bart,

I replied to your private eMail in detail.

In summary I have to start from a fresh Debian install and have
multiple VM machines for many of the problems to ensure my
system is not impacted for day to day. I do not have the
time or machine resources to duplicate that many bugs. Some
issues are likely Debian specific design issues that may shake
things up alot.


Regards,

John L. Males
Toronto, Ontario
Canada
04 July 2012 12:16
<mailto:jlmales@gmail.com>


================================================== ============
2012-07-04 12:06:57.388861181-0400-EDT

4 Jul 12:06:57 ntpdate[17547]: ntpdate 4.2.6p2@1.2194-o Sun
Oct 17 13:35:14 UTC 2010 (1)

4 Jul 12:07:10 ntpdate[17552]: step time server 132.246.11.229
offset 0.000208 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


Message replied to:

Date: Wed, 4 Jul 2012 05:19:42 +0000
From: Bart Martens <bartm@debian.org>
To: debian-devel@lists.debian.org
Subject: Re: Concerns and Challenges of Squeeze and Ongoing
Elements


> On Tue, Jul 03, 2012 at 08:50:20PM -0400, John L. Males wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Ladies and Gentlemen,
>
> I replied to John in detail via a private e-mail. Summary :
> I suggested John to report every problem via bug reports.
>
> Regards,
>
> Bart Martens
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org Archive:
> http://lists.debian.org/20120704051942.GB6057@master.debian.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk/0bbcACgkQ+V/XUtB6aBDokwCg39ywEXpBGfMyhAWRvMwpbZc0
YfkAoMEN6pcUR3FcKLNI0sW04BYaCDlQ
=vm6b
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120704122215.8ba75c89.jlmales@gmail.com">http://lists.debian.org/20120704122215.8ba75c89.jlmales@gmail.com

Concerns and Challenges of Squeeze and Ongoing Elements
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mika,

The keyservers my gpg/pgp keys can be found on include:

<hkp://subkeys.pgp.net>
<hkp://wwwkeys.pgp.net>
<hkp://wwwkeys.us.pgp.net>

Regards,

John L. Males
Toronto, Ontario
Canada
04 July 2012 13:05
<mailto:jlmales@gmail.com>


================================================== ============
2012-07-04 13:01:46.137443564-0400-EDT

4 Jul 13:01:46 ntpdate[17813]: ntpdate 4.2.6p2@1.2194-o Sun
Oct 17 13:35:14 UTC 2010 (1)

4 Jul 13:02:08 ntpdate[17818]: step time server 66.102.79.92
offset 0.002061 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


Message replied to:

Date: Wed, 04 Jul 2012 10:34:45 +0300
From: Mika Suomalainen <mika.henrik.mainio@hotmail.com>
To: debian-devel@lists.debian.org
Subject: Re: Concerns and Challenges of Squeeze and Ongoing
Elements


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04.07.2012 07:10, John L. Males wrote:
> > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
> John, this is a little offtopic, but could you provide link or
> keyserver where we can find your public PGP key. It doesn't
> seem to be on pool.sks-keyservers.net, which I use and seems
> to be one of the most popular keyservers (or keyserver pools).
>
> - --
> Mika Suomalainen
>
> NOTICE! I am on mobile broadband with very limited time, so I
> cannot read emails very much.
> The best time to contact me is probably weekends when I have
> better connectivity with good luck.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Homepage: http://mkaysi.github.com/
> Comment: gpg --keyserver pool.sks-keyservers.net --recv-keys
> 82A46728 Comment: Public key:
> http://mkaysi.github.com/PGP/key.txt Comment: Fingerprint =
> 24BC 1573 B8EE D666 D10A AA65 4DB5 3CFE 82A4 6728 Comment:
> Why do I (clear)sign emails? http://git.io/6FLzWg Comment:
> Please send plaintext instead of HTML. http://git.io/TAc0cg
> Comment: Please don't toppost. http://git.io/7-VB3g Comment:
> Charset of this message should be UTF-8. Comment: Using GnuPG
> with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJP8/ITAAoJEE21PP6CpGcoqrUQAJ8r4nQqjN
> +4iFDyyp2RtGu7 YBx6SPjcsTgagloST0YBA0lCDxsPX
> +he7GVGe6dU9s29koqYCRlvbc/xA+On7WW7
> NrllLSJ42cSLA5XKAEPAY6dR9UbOm6B8XliS1sW12H9ozBoHb/+KYjpfpLxgrORj
> sN39r2b5HAxR0crh690aS3pwF8Y5G6Nku4KAmnsqE8e2
> +OkW84bwWubaeW8Rba/V
> Tseol5pp6ue2ygb0n0DFJmiHQKeicdbQ94ituJTZOsg7JuGe6i F7k5lHZ6LNwthd
> EUnPGV3KtN6CIOci6gzAGKI9tfbgpN0CIsPfq/KHliEFyHYMgPzdi7IbxPOZTBj
> + sizUfVjPzdimUHBULDBkmvCCXgU/CzOTqlGrEM6tg/wT0u916eXZqhwaT
> +Ia2jO4
> W2jf6m4UijGBBssjBn3hZDQFxf9YtMv9uHnfx1LNnLIDfRsdpF lbY6nUlCvwoz/p
> VjYzWWzCJBMknCg0bPDwsPj3S5OOlehGYC0479fF8/Z9SNqzLKGdUST72EdvJlJ4
> 4R7rE/paU+uHxqOOibH7G6lM/iH63cMLK9E4ajrcig
> +7PI/FnACvCnJEjIGk27YL
> 4MUZiv2cka8h0324pRtzrcn1/n5SFzgsnqJXa4D98CMdH11gURYstVmPfGvfiC0P
> 8V5Hu/KYeIOgCyJZMcXJ =NZul
> -----END PGP SIGNATURE-----
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org Archive:
> http://lists.debian.org/4FF3F215.5030206@hotmail.com
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk/0d8MACgkQ+V/XUtB6aBAnSgCfWyTOI1TOMDde7P3+o8gxYqFZ
KcQAnjXXOFYBwP/f8l0SkO0SC/lccQTP
=3B3q
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120704130507.7d0ee037.jlmales@gmail.com">http://lists.debian.org/20120704130507.7d0ee037.jlmales@gmail.com