From: Pavel Machek <pavel@denx.de>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
linux-kernel@vger.kernel.org, Alexander Lobakin <alobakin@pm.me>,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
linux@roeck-us.net, shuah@kernel.org, patches@kernelci.org,
lkft-triage@lists.linaro.org, pavel@denx.de,
jonathanh@nvidia.com, stable@vger.kernel.org
Subject: Re: [PATCH 5.4 00/24] 5.4.105-rc1 review
Date: Sat, 13 Mar 2021 23:30:09 +0100 [thread overview]
Message-ID: <20210313223009.GA12835@amd> (raw)
In-Reply-To: <YEzBQCU/4kk8qcWr@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]
Hi!
> > So I guess we are good, until we are not. It concerns me however that
> > this (latent at the time) issue was reported at Wed, 10 Mar 2021
> > 20:19:48 -0800 which is well before the deadline of Fri, 12 Mar 2021
> > 13:23:09 +0000, and yet, the v5.4.105 was announced on Thu, 11 Mar 2021
> > 05:33:31 -0800 (PST) and it went through with that patch nonetheless.
>
> It's a judgement call on my side as to when to do the release, based on
> the testing that has happened, any reports, and my knowledge of what is
> in the patches themselves. For this patchset, all of the expected
> testers came back with no problems, except for your report.
>
> And if your report turned out to be real (the fact that it was a
> backport of an "old" patch made it much less likely to be real), I can
> always instantly revert it and push out a new release quickly for the
> tiny subset of those that have problems with this.
>
> So I took a guess based on all of this and decided it was more important
> to get the release out early, so that it can start to make its way to
> the huge majority of systems that did report testing worked fine, than
> to delay it to wait for your single system report. Because again, if
> this turned out to be a real issue, a quick release for any affected
> systems would have been trivial to create.
You are setting yourself (and testers) a deadline... and then you
ignore it.
People are not only testing the release, they are also reviewing the
patches, and having at least two days for that is useful.
You clearly disagree, but in any case you should not mention deadline
in the initial if you don't intend to keep them. Thats confusing, and
clearly it is not only confusing to me.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2021-03-13 22:31 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 13:24 [PATCH 5.4 00/24] 5.4.105-rc1 review gregkh
2021-03-10 13:24 ` [PATCH 5.4 01/24] net: dsa: add GRO support via gro_cells gregkh
2021-03-10 13:24 ` [PATCH 5.4 02/24] dm table: fix iterate_devices based device capability checks gregkh
2021-03-10 13:24 ` [PATCH 5.4 03/24] dm table: fix DAX " gregkh
2021-03-10 13:24 ` [PATCH 5.4 04/24] dm table: fix zoned " gregkh
2021-03-10 13:24 ` [PATCH 5.4 05/24] ACPICA: Fix race in generic_serial_bus (I2C) and GPIO op_region parameter handling gregkh
2021-03-10 13:24 ` [PATCH 5.4 06/24] iommu/amd: Fix sleeping in atomic in increase_address_space() gregkh
2021-03-10 13:24 ` [PATCH 5.4 07/24] mwifiex: pcie: skip cancel_work_sync() on reset failure path gregkh
2021-03-10 13:24 ` [PATCH 5.4 08/24] platform/x86: acer-wmi: Cleanup ACER_CAP_FOO defines gregkh
2021-03-10 13:24 ` [PATCH 5.4 09/24] platform/x86: acer-wmi: Cleanup accelerometer device handling gregkh
2021-03-10 13:24 ` [PATCH 5.4 10/24] platform/x86: acer-wmi: Add new force_caps module parameter gregkh
2021-03-10 13:24 ` [PATCH 5.4 11/24] platform/x86: acer-wmi: Add ACER_CAP_SET_FUNCTION_MODE capability flag gregkh
2021-03-10 13:24 ` [PATCH 5.4 12/24] platform/x86: acer-wmi: Add support for SW_TABLET_MODE on Switch devices gregkh
2021-03-10 13:24 ` [PATCH 5.4 13/24] platform/x86: acer-wmi: Add ACER_CAP_KBD_DOCK quirk for the Aspire Switch 10E SW3-016 gregkh
2021-03-10 13:24 ` [PATCH 5.4 14/24] HID: mf: add support for 0079:1846 Mayflash/Dragonrise USB Gamecube Adapter gregkh
2021-03-10 13:24 ` [PATCH 5.4 15/24] media: cx23885: add more quirks for reset DMA on some AMD IOMMU gregkh
2021-03-10 13:24 ` [PATCH 5.4 16/24] ACPI: video: Add DMI quirk for GIGABYTE GB-BXBT-2807 gregkh
2021-03-10 13:24 ` [PATCH 5.4 17/24] ASoC: Intel: bytcr_rt5640: Add quirk for ARCHOS Cesium 140 gregkh
2021-03-10 13:24 ` [PATCH 5.4 18/24] PCI: Add function 1 DMA alias quirk for Marvell 9215 SATA controller gregkh
2021-03-10 13:24 ` [PATCH 5.4 19/24] misc: eeprom_93xx46: Add quirk to support Microchip 93LC46B eeprom gregkh
2021-03-10 13:24 ` [PATCH 5.4 20/24] drm/msm/a5xx: Remove overwriting A5XX_PC_DBG_ECO_CNTL register gregkh
2021-03-10 13:24 ` [PATCH 5.4 21/24] mmc: sdhci-of-dwcmshc: set SDHCI_QUIRK2_PRESET_VALUE_BROKEN gregkh
2021-03-10 13:24 ` [PATCH 5.4 22/24] HID: i2c-hid: Add I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for ITE8568 EC on Voyo Winpad A15 gregkh
2021-03-10 13:24 ` [PATCH 5.4 23/24] nvme-pci: mark Seagate Nytro XM1440 as QUIRK_NO_NS_DESC_LIST gregkh
2021-03-10 13:24 ` [PATCH 5.4 24/24] nvme-pci: add quirks for Lexar 256GB SSD gregkh
2021-03-10 22:00 ` [PATCH 5.4 00/24] 5.4.105-rc1 review Shuah Khan
2021-03-10 23:52 ` Guenter Roeck
2021-03-11 4:05 ` Ross Schmidt
2021-03-11 4:19 ` Florian Fainelli
2021-03-11 13:08 ` Greg KH
2021-03-11 17:23 ` Florian Fainelli
2021-03-11 17:40 ` Greg KH
2021-03-11 17:41 ` Florian Fainelli
2021-03-12 12:54 ` Alexander Lobakin
2021-03-15 9:50 ` Pali Rohár
2021-03-23 17:20 ` Florian Fainelli
2021-03-23 23:32 ` Pali Rohár
2021-03-24 10:26 ` Greg KH
2021-03-12 22:55 ` Florian Fainelli
2021-03-13 13:42 ` Greg KH
2021-03-13 22:30 ` Pavel Machek [this message]
2021-03-11 7:34 ` Naresh Kamboju
2021-03-11 9:42 ` Samuel Zou
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=20210313223009.GA12835@amd \
--to=pavel@denx.de \
--cc=akpm@linux-foundation.org \
--cc=alobakin@pm.me \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lkft-triage@lists.linaro.org \
--cc=patches@kernelci.org \
--cc=shuah@kernel.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.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