From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Ray Lee <ray-lk@madrabbit.org>
Cc: Matt Mackall <mpm@selenic.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
akpm@linux-foundation.org
Subject: Re: 2.6.21-mm2: ACPI exception on resume
Date: Wed, 23 May 2007 21:28:26 -0300 [thread overview]
Message-ID: <20070524002826.GA2644@khazad-dum.debian.net> (raw)
In-Reply-To: <2c0942db0705231550x70432ceaw1d428d7a25ffe8aa@mail.gmail.com>
On Wed, 23 May 2007, Ray Lee wrote:
> The problem is when the maintainers/submitters get the wrong
> impression, that 2.6.x.y is there to clean up the mess they made. The
Now, that I agree with completely.
> Which is the crux of my problem with your statement. I feel we
> shouldn't give the wrong idea to those authors. They need to know that
> the expectation is that 2.6.x is a stable series, and 2.6.x.y is for
> dealing with unavoidable mistakes.
Well, the only case where I feel a regression is justified is one where it
is caused by a bug in the firmware or the hardware.
At which point my personal opinion is that users of firmware/hardware *that
have a fix available* are to be told to apply the fix, unless the problem is
so serious that it could potentially cause extreme damage (loss of human
life, permanent hardware damage, major data loss).
If there is no fix the user can apply, then it really depends on how
damaging it is to work around the issue for others: you don't punish those
who have non-broken stuff to avoid problems for those that have broken
stuff.
Fortunately, most of the time one can come up with a fix that causes little
to no loss to those with non-broken hardware/firmware.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2007-05-24 0:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-19 16:57 2.6.21-mm2: ACPI exception on resume Matt Mackall
2007-05-19 18:24 ` Rafael J. Wysocki
2007-05-19 22:40 ` Matt Mackall
2007-05-19 23:05 ` Rafael J. Wysocki
2007-05-19 20:45 ` Henrique de Moraes Holschuh
2007-05-19 22:38 ` Matt Mackall
2007-05-20 3:52 ` Henrique de Moraes Holschuh
2007-05-21 22:23 ` Matt Mackall
2007-05-21 23:03 ` Henrique de Moraes Holschuh
2007-05-22 22:45 ` Matt Mackall
2007-05-23 0:19 ` Henrique de Moraes Holschuh
2007-05-23 1:48 ` Matt Mackall
2007-05-23 4:19 ` Henrique de Moraes Holschuh
2007-05-23 4:41 ` Ray Lee
2007-05-23 12:51 ` Henrique de Moraes Holschuh
2007-05-23 22:50 ` Ray Lee
2007-05-24 0:28 ` Henrique de Moraes Holschuh [this message]
2007-05-24 1:37 ` Ray Lee
2007-05-27 21:02 ` Pavel Machek
2007-05-23 8:57 ` Rafael J. Wysocki
2007-05-23 17:13 ` Henrique de Moraes Holschuh
2007-05-23 17:48 ` Matt Mackall
2007-05-23 20:56 ` Rafael J. Wysocki
2007-05-23 21:15 ` Matt Mackall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070524002826.GA2644@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=akpm@linux-foundation.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=ray-lk@madrabbit.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox