| Message ID | 20230424072836.GAZEYvpDGrV3bXx690@fat_crate.local (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [GIT,PULL] EDAC updates for v6.4 | expand |
On Mon, Apr 24, 2023 at 12:28 AM Borislav Petkov <bp@alien8.de> wrote: > > For some stupid reason (juggling gazillion things at the same time, > probably) I have based the edac-amd64 branch *not* ontop of plain > v6.3-rc3 but there are a couple more of your merges ontop. It's fine. Mistakes happen, and honestly, the "base your work on top of a stable point" is - like almost everything else in life - a recommendation for everybody's sanity, rather than any kind of black-and-white rule. And it comes mainly from people actively mis-using git, and merging random upstream state without thought, and trying to set that kind of behavior right, and have people _think_ about it. IOW, it's not some "this gets enforced" thing - it's more of a "you did something else horribly wrong, so let's clarify what the 'good thoughtful git behavior' should be". Sometimes starting at a random point can even be a feature - random cleanups that depend on some helper that was added last release, and it's just much more convenient to start at point X ratherr than wait for the next -rc. Now, the thing I do hope that people actively try to avoid is picking a "kernel of the day" during the merge window to start on, but even that is less about "well-defined starting point" and more about just the fact that the merge window kernel *can* be really unstable and is a really bad base. But some "rc3+" kernel is certainly not that kind of _horribly_ bad kernel to start at. It's probably better than starting at a rc1 release in practice. So the "try to use a reasonably stable starting point" really is a general recommendation, and mostly a reaction against people who tend to do more of a mindless "rebase/merge to today's kernels without any thought" kind of workflow. So I'm not asking for surgical precision. I'm asking for "reasonable workflow", where people avoid doing pointlessly silly things. Linus
On Tue, Apr 25, 2023 at 09:55:14AM -0700, Linus Torvalds wrote: > So I'm not asking for surgical precision. I'm asking for "reasonable > workflow", where people avoid doing pointlessly silly things. As always, I really appreciate elaborating on the whole reasoning behind this. While we're on the topic: when we send you tip urgent fixes, we base each branch off of the current -rc, put the urgent fixes ontop, test, ... and send them to you in a week's time, roughly. Now, after you've pulled, we could fast-forward the urgent branch to the next -rc where new fixes come - and I do that most of the time - or we could not do that because of, as you say, if there's no really good reason to fast-forward (important other fix, new functionality from the newest -rc a patch needs, yadda yadda) then those urgent branches do not necessarily have to be fast-forwarded but simply get more fixes applied ontop. Right, that makes sense. Oh, and I'm sure if a branch is based on what looks like a random point but there's a good explanation accompanying it why it is based on that random point, then I guess that's perfectly fine too. Thx.
On Tue, Apr 25, 2023 at 10:35 AM Borislav Petkov <bp@alien8.de> wrote: > > While we're on the topic: when we send you tip urgent fixes, we base > each branch off of the current -rc, put the urgent fixes ontop, test, > ... and send them to you in a week's time, roughly. > > Now, after you've pulled, we could fast-forward the urgent branch to the > next -rc where new fixes come - and I do that most of the time - or we > could not do that because of, as you say, if there's no really good > reason to fast-forward (important other fix, new functionality from the > newest -rc a patch needs, yadda yadda) then those urgent branches do not > necessarily have to be fast-forwarded but simply get more fixes applied > ontop. That sounds right. Do the fast-forward thing if you want to update to a newer rc for some other reason, but if there's no major other thing going on, you can easily just continue on top of your existing fixes branch. There's no reason to actively seek a new base if you already had a stable base that you were on. So whatever works best for you. (Of course, at some point "that base is just _really_ old" becomes a reason in itself, and then fast-forwarding to have a newer base to do your fixes on top just becomes a convenience) > Oh, and I'm sure if a branch is based on what looks like a random point > but there's a good explanation accompanying it why it is based on that > random point, then I guess that's perfectly fine too. Absolutely. Things that look wrong when I look at the pull request result may have good reasons for them. If you know there's something odd going on but you had a particular reason to do it that way, just mention it. For example - I can get quite upset when I see that all the commits are very recent and have clearly not had a lot of testing. But if that isn't your usual pattern, and you had a clear *reason* for the commits all being shiny and new ("I had to rebase to remove a completely broken commit"), please mention it. Of course, if that particular reason keeps on happening, and there' sa continual stream of "I know I did things wrong, but it was because of X", then maybe that "X" is a huge problem and should be fixed? So the occasional oddity with explanations is perfectly fine. But a consistent _pattern_ of oddities is a problem, explanations notwithstanding. Linus
The pull request you sent on Mon, 24 Apr 2023 09:28:36 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/edac_updates_for_v6.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e94ee641f9cef2502adfe5e0c264b271420c7ab5
Thank you!
Hi Linus, please pull the latest lineup of EDAC changes for v6.4. For some stupid reason (juggling gazillion things at the same time, probably) I have based the edac-amd64 branch *not* ontop of plain v6.3-rc3 but there are a couple more of your merges ontop. I.e., the actual base is v6.3-rc3-12-g17214b70a159, as it says below. The branch is otherwise fine, those merges are unrelated, it has passed testing and has been in linux-next for almost a month now. I didn't want to rebase to have a clean base because that would've altered commit IDs and that's a no-no. So pls lemme know if there's something I need to do or whether that looks ok this way. Thanks and sorry. --- The following changes since commit 17214b70a159c6547df9ae204a6275d983146f6b: Merge tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux (2023-03-20 15:20:33 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/edac_updates_for_v6.4 for you to fetch changes up to ce8ac91130b96f651cf6b5245668dfa4969c9c42: Merge branches 'edac-drivers', 'edac-amd64' and 'edac-misc' into edac-updates (2023-04-24 09:14:30 +0200) ---------------------------------------------------------------- - skx_edac: Fix overflow when decoding 32G DIMM ranks - i10nm_edac: Add Sierra Forest support - amd64_edac: Split driver code between legacy and SMCA systems. The final goal is adding support for more hw, like GPUs - The usual minor cleanups and fixes ---------------------------------------------------------------- Borislav Petkov (AMD) (2): EDAC: Sanitize MODULE_AUTHOR strings Merge branches 'edac-drivers', 'edac-amd64' and 'edac-misc' into edac-updates Deepak R Varma (1): EDAC/altera: Remove redundant error logging Jonathan Neuschäfer (1): EDAC/amd81[13]1: Remove trailing newline from MODULE_AUTHOR Jongwoo Han (1): EDAC/i5100: Fix typo in comment Muralidhara M K (11): EDAC/amd64: Merge struct amd64_family_type into struct amd64_pvt EDAC/amd64: Split prep_chip_selects() into dct/umc functions EDAC/amd64: Split read_base_mask() into dct/umc functions EDAC/amd64: Split determine_memory_type() into dct/umc functions EDAC/amd64: Split read_mc_regs() into dct/umc functions EDAC/amd64: Split ecc_enabled() into dct/umc functions EDAC/amd64: Split setup_mci_misc_attrs() into dct/umc functions EDAC/amd64: Split determine_edac_cap() into dct/umc functions EDAC/amd64: Split init_csrows() into dct/umc functions EDAC/amd64: Split dump_misc_regs() into dct/umc functions EDAC/amd64: Add get_err_info() to pvt->ops Nick Alcock (1): EDAC/altera: Remove MODULE_LICENSE in non-module Qiuxu Zhuo (2): EDAC/skx: Fix overflows on the DRAM row address mapping arrays EDAC/i10nm: Add Intel Sierra Forest server support Yang Li (1): EDAC/amd64: Fix indentation in umc_determine_edac_cap() Yazen Ghannam (6): EDAC/amd64: Rename debug_display_dimm_sizes() EDAC/amd64: Split get_csrow_nr_pages() into dct/umc functions EDAC/amd64: Drop dbam_to_cs() for Family 17h and later EDAC/amd64: Do not discover ECC symbol size for Family 17h and later EDAC/amd64: Rework hw_info_{get,put} EDAC/amd64: Rename f17h_determine_edac_ctl_cap() drivers/edac/altera_edac.c | 10 +- drivers/edac/amd64_edac.c | 1020 ++++++++++++++++++---------------------- drivers/edac/amd64_edac.h | 67 +-- drivers/edac/amd8111_edac.c | 2 +- drivers/edac/amd8131_edac.c | 2 +- drivers/edac/e752x_edac.c | 2 +- drivers/edac/e7xxx_edac.c | 3 +- drivers/edac/i10nm_base.c | 1 + drivers/edac/i5000_edac.c | 7 +- drivers/edac/i5100_edac.c | 5 +- drivers/edac/i82860_edac.c | 3 +- drivers/edac/layerscape_edac.c | 3 +- drivers/edac/mpc85xx_edac.c | 3 +- drivers/edac/r82600_edac.c | 3 +- drivers/edac/skx_base.c | 4 +- 15 files changed, 490 insertions(+), 645 deletions(-)