From: Peter Korsgaard <peter@korsgaard.com>
To: Jean Delvare <jdelvare@suse.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "firmware: dmi_scan: Use lowercase letters for UUID"
Date: Tue, 11 Dec 2018 15:36:51 +0100 [thread overview]
Message-ID: <87a7lct9j0.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <1544536167.5269.7.camel@suse.com> (Jean Delvare's message of "Tue, 11 Dec 2018 14:49:27 +0100")
>>>>> "Jean" == Jean Delvare <jdelvare@suse.com> writes:
> On Tue, 2018-12-11 at 13:06 +0100, Peter Korsgaard wrote:
>> > > > > > "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
>>
>> Hi Jean,
>>
>> >> Look, you can imagine that I was perfectly aware of what I was doing
>> >> when I made that change, and that I pondered the decision carefully at
>> >> that time. And my decision was that the change should be made. As far
>> >> as I'm concerned, this ship has sailed already, sorry.
>>
>> > Sorry, what is the perceived risk of reverting this change? Just the
>> > minor inconsistency between the dmidecode and sysfs output? As stated
>> > above, the RFC requires conforming parsers to handle upper case as well.
>>
>> I would appreciate if you could explain what risk you see from reverting
>> this change?
> The exact same risk that you are complaining about, for a different
> pair of kernel versions. You cannot at the same time argue that the
> change should not have been done back then, and ask for same change to
> be done again now.
With that kind of catch-22 logic, no regressions can ever be fixed. This
change was part of 4.17, released 6 months ago, whereas the previous
behaviour has existed for an order of magnitude longer.
While it is true that there is a chance that somebody may rely on the
new behaviour, it is likely to be significantly smaller than the chance
that someone relied on the previous behaviour (E.G. the breakage in my
software is proof of at least one such instance). Given that 4.19 has
only recently become a LTS kernel and distibutions with 4.17+ are only
getting released now (Fedora 29, Ubuntu 18.10) chances are that more
people will be affected in the future.
But you are right, we should do the revert as soon as possible, before
people start relying on this new behaviour.
I can extend the commit message with a reference to RFC4122 if you
prefer that over my "the change was purely cosmetical" wording?
--
Bye, Peter Korsgaard
prev parent reply other threads:[~2018-12-11 14:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 21:13 Peter Korsgaard
2018-12-05 21:36 ` Peter Korsgaard
2018-12-06 8:54 ` Jean Delvare
2018-12-06 9:22 ` Peter Korsgaard
2018-12-06 10:28 ` Jean Delvare
2018-12-06 15:46 ` Peter Korsgaard
2018-12-11 12:06 ` Peter Korsgaard
2018-12-11 13:49 ` Jean Delvare
2018-12-11 14:36 ` Peter Korsgaard [this message]
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=87a7lct9j0.fsf@dell.be.48ers.dk \
--to=peter@korsgaard.com \
--cc=jdelvare@suse.com \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®