Message ID | CAJvTdKmK_U7nChpm=MzaDyw3T9V6hSua-6C89WCjo828vxm+yw@mail.gmail.com (mailing list archive) |
---|---|
State | Mainlined, archived |
Headers | show |
Series | [GIT,PULL] turbostat 2024.04.10 | expand |
The pull request you sent on Wed, 10 Apr 2024 09:24:19 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git tags/turbostat-2024.04.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a6189a7407795b3f5167ea532ac85931cd26083a
Thank you!
On Wed, 10 Apr 2024 at 06:24, Len Brown <lenb@kernel.org> wrote: > > Turbostat version 2024.04.10 Tssk. Things like this should still come in during the merge window and preferably be in linux-next. I have pulled this, since it's obviously just tooling (and the maintainer file pattern update), but stil... Linus
On Wed, Apr 10, 2024 at 4:18 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Wed, 10 Apr 2024 at 06:24, Len Brown <lenb@kernel.org> wrote: > > > > Turbostat version 2024.04.10 > > Tssk. Things like this should still come in during the merge window > and preferably be in linux-next. > > I have pulled this, since it's obviously just tooling (and the > maintainer file pattern update), but stil... ISTR that once upon a time at the kernel summit you expressed a preference that things like utilities (which sometimes depend on merge window changes) come in after rc1 is declared to basically stay out of the way. Yes, this batch was delayed a week or so after that due to some revisions... Happy to send this kind of thing during the merge window when dependencies allow (yes, they would have this time) since that is your current preference. Also, yes, I can have my turbostat branch routinely included in linux-next. thanks, -Len
On Thu, 11 Apr 2024 at 11:20, Len Brown <lenb@kernel.org> wrote: > > ISTR that once upon a time at the kernel summit you expressed a > preference that things like utilities (which sometimes depend on merge > window changes) come in after rc1 is declared to basically stay out of > the way. That may have been true at some point, but probably long ago - the merge windows have been so reliable that it's just not an issue any more. So I'd rather see people hold to the normal release cycle, and aim to have the rc releases for fixes or major problems. We also used to allow entirely new drivers etc outside the release cycle as a "this cannot regress" exception to the normal rules, but that has also been largely abandoned as the release cycle is just short enough that it makes no sense. So the "new hardware support" rule has basically been watered down over the years, and has become a "new hardware IDs are fine" kind of rule, where just adding basically just a PCI ID or OF matching entry or similar is still fine, but no more "whole new drivers". Linus