* Linux 4.12-rc1 @ 2017-05-13 20:57 ` Linus Torvalds 2017-05-14 17:59 ` Linux 4.12-rc1 (file locations) Randy Dunlap 2017-05-15 13:15 ` linux-next: stats (Was: Linux 4.12-rc1) Stephen Rothwell 0 siblings, 2 replies; 16+ messages in thread From: Linus Torvalds @ 2017-05-13 20:57 UTC (permalink / raw) To: Linux Kernel Mailing List So I'm doing this one day early, because I don't like last-minute pull requests during the merge window anyway, and tomorrow is mother's day, so I may end up being roped into various happenings. Besides, this has actually been a pretty large merge window, so despite there technically being time for one more day of pulls, I actually do have enough changes already. So there. Despite it being fairly large, it has (so far) been pretty smooth. I don't think I personally saw any breakage at all, which is always nice. Usually I end up having something break, or trigger some silly build failure that really should have been noticed before it even got to me, but so far things are looking good. Famous last words. The diffstat for this release looks a bit odd, because it's absolutely dominated by the new AMD Vega10 header files that have all the register definitions in them. In fact, that's almost exactly half the lines of diff in just that. And if you ignore that part, the new Intel Atom IPU driver ends up being a noticeable part of the rest. But if you ignore those two big additions, the statistics look pretty normal. Two thirds drivers, with the rest being arch updates, documentation updates and "misc" (filesystems, networking, header updates, core files). One thing worth noting - I haven't uploaded diffs or tar-balls for this rc. Those should now be automagically generated by kernel.org for the rc's, but that also means that they won't be signed by my key. If you really care about signing, get the git repo and check the tag. Go test. Linus --- Al Viro (7): uaccess unification updates iov_iter updates splice updates fs/compat.c cleanups vfs fix misc vfs updates misc vfs updates Alex Williamson (1): VFIO updates Alexandre Belloni (1): RTC updates Andrew Morton (3): misc updates more updates misc fixes Arnd Bergmann (1): TEE driver infrastructure and OP-TEE drivers Bartlomiej Zolnierkiewicz (1): fbdev updates Bjorn Helgaas (1): PCI updates Bob Peterson (1): GFS2 updates Borislav Petkov (1): EDAC updates Brian Norris (1): MTD updates Bruce Fields (1): nfsd updates Catalin Marinas (2): arm64 updates more arm64 updates Chris Mason (1): btrfs updates Corey Minyard (1): IPMI updates Dan Williams (2): libnvdimm updates libnvdimm fixes Darren Hart (1): x86 platform-drivers update Darrick Wong (1): xfs updates Dave Airlie (4): drm u pdates drm tegra updates drm CoC pointer drm fixes David Howells (1): hw lockdown support David Millar (1): networking updates David Miller (4): networking fixes networking fixes sparc updates IDE updates Dmitry Torokhov (2): input subsystem updates some more input subsystem updates Doug Ledford (2): rdma updates more rdma updates Eric Biederman (1): namespace updates Geert Uytterhoeven (1): m68k updates Greg KH (5): USB updates driver core updates char/misc driver updates staging/IIO updates tty/serial updates Guenter Roeck (1): hwmon updates Hans-Christian Noren Egtvedt (1): AVR32 removal Herbert Xu (1): crypto updates Ilya Dryomov (1): ceph updates Ingo Molnar (21): EFI updates scheduler updates locking updates perf updates RAS updates x86 boot updates x86 cpu updates x86 apic updates x86 asm updates x86 build update x86 cleanups x86 debug updates x86 irq update x86 platform updates x86 vdso updates x86 mm updates RCU updates x86 fixes stackprotector fixlet timer fix perf updates/fixes Jacek Anaszewski (1): LED updates Jaegeuk Kim (1): f2fs updates James Bottomley (1): SCSI updates James Hogan (2): metag updates MIPS updates James Morris (1): security subsystem updates Jan Kara (2): fsnotify updates quota, reiserfs, udf and ext2 updates Jassi Brar (1): mailbox updates Jens Axboe (4): block layer updates second round of block layer updates block fixes and updates block fixes Jessica Yu (1): modules updates Jiri Kosina (3): HID subsystem updates livepatch updates trivial tree updates Joerg Roedel (1): IOMMU updates Jonathan Corbet (2): documentation update more documentation updates Juergen Gross (2): xen updates xen fixes Kees Cook (2): pstore updates hardened usercopy updates Lee Jones (2): backlight update MFD updates Ley Foon Tan (1): nios2 updates Linus Walleij (2): pin control updates GPIO updates Luis de Bethencourt (1): befs fix Mark Brown (2): regulator updates spi updates Martin Schwidefsky (1): s390 updates Masahiro Yamada (3): Kbuild updates misc Kbuild updates Kbuild UAPI updates Mauro Carvalho Chehab (1): media updates Max Filippov (1): Xtensa updates Michael Ellerman (2): powerpc updates more powerpc updates Michael Tsirkin (1): virtio updates Mike Marshall (1): orangefs updates Mike Snitzer (3): device mapper updates additional device mapper updates device mapper fixes Miklos Szeredi (2): fuse updates overlayfs update Nicholas Bellinger (1): SCSI target updates Olof Johansson (7): misc ARM SoC fixes ARM SoC platform updates ARM Device-tree updates ARM: SoC defconfig updates ARM SoC driver updates ARM SoC 64-bit changes ARM 64-bit DT updates Paolo Bonzini (2): KVM updates more KVM updates Paul Moore (1): audit updates Petr Mladek (1): printk updates Rafael Wysocki (5): power management updates ACPI updates generic device properties framework updates more power management updates more ACPI updates Richard Weinberger (2): UML fixes UBI/UBIFS updates Rob Herring (1): DeviceTree updates Russell King (1): ARM updates Sebastian Reichel (3): power supply and reset updates HSI fix more power-supply updates Shaohua Li (1): MD updates Shuah Khan (1): kselftest updates Stafford Horne (1): initramfs fix Stephen Boyd (1): clk updates Steve French (2): CIFS fixes cifs fixes Steven Rostedt (3): tracing updates more tracing updates tracing fix Takashi Iwai (2): sound updates sound fixes Ted Ts'o (2): ext4 updates fscrypt updates Tejun Heo (3): libata updates workqueue update cgroup updates Thierry Reding (1): pwm updates Thomas Gleixner (2): irq updates timer updates Trond Myklebust (1): NFS client updates Ulf Hansson (1): MMC updates Vineet Gupta (1): ARC updates Vinod Koul (1): dmaengine updates Wilfram Sang (1): i2c updates Zhang Rui (1): thermal management updates ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Linux 4.12-rc1 (file locations) 2017-05-13 20:57 ` Linux 4.12-rc1 Linus Torvalds @ 2017-05-14 17:59 ` Randy Dunlap 2017-05-15 15:42 ` Linus Torvalds 2017-05-15 18:45 ` Konstantin Ryabitsev via RT 2017-05-15 13:15 ` linux-next: stats (Was: Linux 4.12-rc1) Stephen Rothwell 1 sibling, 2 replies; 16+ messages in thread From: Randy Dunlap @ 2017-05-14 17:59 UTC (permalink / raw) To: Linus Torvalds, Linux Kernel Mailing List, helpdesk On 05/13/17 13:57, Linus Torvalds wrote: > One thing worth noting - I haven't uploaded diffs or tar-balls for > this rc. Those should now be automagically generated by kernel.org for > the rc's, but that also means that they won't be signed by my key. If > you really care about signing, get the git repo and check the tag. There was some delay (don't know how much), but a bigger problem is the file(s) locations and (new) directory structure for them. Can the generated files please be put in the same places that (most or all) previous releases have used? Oh, and the patch file (on https://kernel.org) is a text file, not a zipped file (as in previous releases). thanks. -- ~Randy ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Linux 4.12-rc1 (file locations) 2017-05-14 17:59 ` Linux 4.12-rc1 (file locations) Randy Dunlap @ 2017-05-15 15:42 ` Linus Torvalds 2017-05-15 15:42 ` [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] " Linus Torvalds via RT [not found] ` <rt-4.4.0-31807-1494862968-1551.40777-6-0@linuxfoundation> 2017-05-15 18:45 ` Konstantin Ryabitsev via RT 1 sibling, 2 replies; 16+ messages in thread From: Linus Torvalds @ 2017-05-15 15:42 UTC (permalink / raw) To: Randy Dunlap, Konstantin Ryabitsev; +Cc: Linux Kernel Mailing List, helpdesk On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap <rdunlap@infradead.org> wrote: > > Can the generated files please be put in the same places that (most or > all) previous releases have used? I will leave this to Konstantin.. There may well be practical reasons for the movement. > Oh, and the patch file (on https://kernel.org) is a text file, not a > zipped file (as in previous releases). Well, if you use a browser, the normal browser compression (behind your back) should be in effect. So you won't actually be wasting the bandwidth. If you use wget, you have to manually ask for it. Quoting Konstantin from an earlier discussion: > Yes, this is implemented on the http protocol level -- but you have to > tell wget to request it: > > wget -O test.patch.gz \ > --header="accept-encoding: gzip" \ > https://git.kernel.org/... > > Browsers do the requesting and ungzipping automatically, but not cmdline > tools. so the capability is there, it's just not done as several individual files any more. Linus ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations) 2017-05-15 15:42 ` Linus Torvalds @ 2017-05-15 15:42 ` Linus Torvalds via RT 2017-05-15 18:34 ` François Valenduc [not found] ` <rt-4.4.0-31807-1494862968-1551.40777-6-0@linuxfoundation> 1 sibling, 1 reply; 16+ messages in thread From: Linus Torvalds via RT @ 2017-05-15 15:42 UTC (permalink / raw) To: rdunlap; +Cc: linux-kernel On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap <rdunlap@infradead.org> wrote: > > Can the generated files please be put in the same places that (most or > all) previous releases have used? I will leave this to Konstantin.. There may well be practical reasons for the movement. > Oh, and the patch file (on https://kernel.org) is a text file, not a > zipped file (as in previous releases). Well, if you use a browser, the normal browser compression (behind your back) should be in effect. So you won't actually be wasting the bandwidth. If you use wget, you have to manually ask for it. Quoting Konstantin from an earlier discussion: > Yes, this is implemented on the http protocol level -- but you have to > tell wget to request it: > > wget -O test.patch.gz \ > --header="accept-encoding: gzip" \ > https://git.kernel.org/... > > Browsers do the requesting and ungzipping automatically, but not cmdline > tools. so the capability is there, it's just not done as several individual files any more. Linus ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations) 2017-05-15 15:42 ` [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] " Linus Torvalds via RT @ 2017-05-15 18:34 ` François Valenduc 2017-05-15 18:34 ` François Valenduc via RT [not found] ` <rt-4.4.0-31767-1494873296-832.40777-6-0@linuxfoundation> 0 siblings, 2 replies; 16+ messages in thread From: François Valenduc @ 2017-05-15 18:34 UTC (permalink / raw) To: kernel-helpdesk, linux-kernel Le 15/05/17 à 17:42, Linus Torvalds via RT a écrit : > On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap <rdunlap@infradead.org> wrote: >> >> Can the generated files please be put in the same places that (most or >> all) previous releases have used? > > I will leave this to Konstantin.. There may well be practical reasons > for the movement. > >> Oh, and the patch file (on https://kernel.org) is a text file, not a >> zipped file (as in previous releases). > > Well, if you use a browser, the normal browser compression (behind > your back) should be in effect. So you won't actually be wasting the > bandwidth. > > If you use wget, you have to manually ask for it. Quoting Konstantin > from an earlier discussion: > >> Yes, this is implemented on the http protocol level -- but you have to >> tell wget to request it: >> >> wget -O test.patch.gz \ >> --header="accept-encoding: gzip" \ >> https://git.kernel.org/... >> >> Browsers do the requesting and ungzipping automatically, but not cmdline >> tools. > > so the capability is there, it's just not done as several individual > files any more. > > Linus > > It doesn't work with Firefox-53.0. After quite a long time while firefox uses 100% of CPU, I finally get a text file and not a gzip file of the patch for 4.12-rc1. It was almost instantaneous previously. I don't see this as a progress. Best regards, François Valenduc ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations) 2017-05-15 18:34 ` François Valenduc @ 2017-05-15 18:34 ` François Valenduc via RT [not found] ` <rt-4.4.0-31767-1494873296-832.40777-6-0@linuxfoundation> 1 sibling, 0 replies; 16+ messages in thread From: François Valenduc via RT @ 2017-05-15 18:34 UTC (permalink / raw) To: rdunlap; +Cc: linux-kernel, torvalds Le 15/05/17 à 17:42, Linus Torvalds via RT a écrit : > On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap <rdunlap@infradead.org> wrote: >> >> Can the generated files please be put in the same places that (most or >> all) previous releases have used? > > I will leave this to Konstantin.. There may well be practical reasons > for the movement. > >> Oh, and the patch file (on https://kernel.org) is a text file, not a >> zipped file (as in previous releases). > > Well, if you use a browser, the normal browser compression (behind > your back) should be in effect. So you won't actually be wasting the > bandwidth. > > If you use wget, you have to manually ask for it. Quoting Konstantin > from an earlier discussion: > >> Yes, this is implemented on the http protocol level -- but you have to >> tell wget to request it: >> >> wget -O test.patch.gz \ >> --header="accept-encoding: gzip" \ >> https://git.kernel.org/... >> >> Browsers do the requesting and ungzipping automatically, but not cmdline >> tools. > > so the capability is there, it's just not done as several individual > files any more. > > Linus > > It doesn't work with Firefox-53.0. After quite a long time while firefox uses 100% of CPU, I finally get a text file and not a gzip file of the patch for 4.12-rc1. It was almost instantaneous previously. I don't see this as a progress. Best regards, François Valenduc ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <rt-4.4.0-31767-1494873296-832.40777-6-0@linuxfoundation>]
* [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) [not found] ` <rt-4.4.0-31767-1494873296-832.40777-6-0@linuxfoundation> @ 2017-05-15 18:42 ` Konstantin Ryabitsev via RT 2017-05-24 18:34 ` Christian Kujau 0 siblings, 1 reply; 16+ messages in thread From: Konstantin Ryabitsev via RT @ 2017-05-15 18:42 UTC (permalink / raw) To: rdunlap; +Cc: linux-kernel, torvalds On 2017-05-15 14:34:56, francoisvalenduc@gmail.com wrote: > It doesn't work with Firefox-53.0. After quite a long time while > firefox > uses 100% of CPU, I finally get a text file and not a gzip file of the > patch for 4.12-rc1. It was almost instantaneous previously. I don't > see > this as a progress. Firefox will request a gzip version of the patch, download it and then ungzip it for you and display it in the browser. If you'd rather not display that, please use a commandline tool like wget or curl to get the patch. We are trying to identify who are the people who still need to download patches as opposed to using git directly, and what their use-case scenario is. Regards, -- Konstantin Ryabitsev Senior Systems Administrator Linux Foundation Collab Projects Montréal, Québec ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) 2017-05-15 18:42 ` [Kernel.org Helpdesk " Konstantin Ryabitsev via RT @ 2017-05-24 18:34 ` Christian Kujau 2017-05-24 18:42 ` Christian Kujau via RT [not found] ` <rt-4.4.0-12250-1495651374-7.40777-6-0@linuxfoundation> 0 siblings, 2 replies; 16+ messages in thread From: Christian Kujau @ 2017-05-24 18:34 UTC (permalink / raw) To: Konstantin Ryabitsev via RT; +Cc: rdunlap, linux-kernel, torvalds On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote: > On 2017-05-15 14:34:56, francoisvalenduc@gmail.com wrote: > > It doesn't work with Firefox-53.0. After quite a long time while > > firefox > > uses 100% of CPU, I finally get a text file and not a gzip file of the > > patch for 4.12-rc1. It was almost instantaneous previously. I don't > > see > > this as a progress. > > Firefox will request a gzip version of the patch, download it and then ungzip > it for you and display it in the browser. If you'd rather not display > that, please use a commandline tool like wget or curl to get the patch. Yeah, same here: clicking on 4.12-rc2/patch on the kernel.org main page makes Firefox 53 freeze for a few minutes, and then display (!) the text file (85 MB!) in full. Wow. > We are trying to identify who are the people who still need to download > patches as opposed to using git directly, and what their use-case I never use the links on the kernel.org main page to download patches, but still: can those be changed to say ".gz" or something, so that $browser won't _display_ it by default but _download_ it instead? Thanks, Christian. -- BOFH excuse #435: Internet shut down due to maintenance ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) 2017-05-24 18:34 ` Christian Kujau @ 2017-05-24 18:42 ` Christian Kujau via RT [not found] ` <rt-4.4.0-12250-1495651374-7.40777-6-0@linuxfoundation> 1 sibling, 0 replies; 16+ messages in thread From: Christian Kujau via RT @ 2017-05-24 18:42 UTC (permalink / raw) To: rdunlap; +Cc: linux-kernel, torvalds On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote: > On 2017-05-15 14:34:56, francoisvalenduc@gmail.com wrote: > > It doesn't work with Firefox-53.0. After quite a long time while > > firefox > > uses 100% of CPU, I finally get a text file and not a gzip file of the > > patch for 4.12-rc1. It was almost instantaneous previously. I don't > > see > > this as a progress. > > Firefox will request a gzip version of the patch, download it and then ungzip > it for you and display it in the browser. If you'd rather not display > that, please use a commandline tool like wget or curl to get the patch. Yeah, same here: clicking on 4.12-rc2/patch on the kernel.org main page makes Firefox 53 freeze for a few minutes, and then display (!) the text file (85 MB!) in full. Wow. > We are trying to identify who are the people who still need to download > patches as opposed to using git directly, and what their use-case I never use the links on the kernel.org main page to download patches, but still: can those be changed to say ".gz" or something, so that $browser won't _display_ it by default but _download_ it instead? Thanks, Christian. -- BOFH excuse #435: Internet shut down due to maintenance ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <rt-4.4.0-12250-1495651374-7.40777-6-0@linuxfoundation>]
* [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) [not found] ` <rt-4.4.0-12250-1495651374-7.40777-6-0@linuxfoundation> @ 2017-05-24 20:14 ` Konstantin Ryabitsev via RT 0 siblings, 0 replies; 16+ messages in thread From: Konstantin Ryabitsev via RT @ 2017-05-24 20:14 UTC (permalink / raw) To: rdunlap; +Cc: linux-kernel, torvalds On 2017-05-24 14:42:54, lists@nerdbynature.de wrote: > > We are trying to identify who are the people who still need to > > download > > patches as opposed to using git directly, and what their use-case > > I never use the links on the kernel.org main page to download patches, > but > still: can those be changed to say ".gz" or something, so that > $browser > won't _display_ it by default but _download_ it instead? We'll enable that the moment cgit supports that -- but it currently doesn't. I have an RFE open with cgit upstream. Regards, -- Konstantin Ryabitsev Linux Foundation Projects ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <rt-4.4.0-31807-1494862968-1551.40777-6-0@linuxfoundation>]
* [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) [not found] ` <rt-4.4.0-31807-1494862968-1551.40777-6-0@linuxfoundation> @ 2017-05-16 21:22 ` Konstantin Ryabitsev via RT 0 siblings, 0 replies; 16+ messages in thread From: Konstantin Ryabitsev via RT @ 2017-05-16 21:22 UTC (permalink / raw) To: rdunlap; +Cc: linux-kernel, torvalds On 2017-05-15 11:42:48, torvalds@linux-foundation.org wrote: > so the capability is there, it's just not done as several individual > files any more. I've published a news item explaining the new process and the reasoning behind not providing these automatically generated tarballs and patches as part of the cryptographically verifiable /pub tree: https://www.kernel.org/rc-tarballs-and-patches-starting-with-412-rc1.html Regards, -- Konstantin Ryabitsev Director, IT Infrastructure Security Linux Foundation Projects Montréal, Québec ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) 2017-05-14 17:59 ` Linux 4.12-rc1 (file locations) Randy Dunlap 2017-05-15 15:42 ` Linus Torvalds @ 2017-05-15 18:45 ` Konstantin Ryabitsev via RT 1 sibling, 0 replies; 16+ messages in thread From: Konstantin Ryabitsev via RT @ 2017-05-15 18:45 UTC (permalink / raw) To: rdunlap; +Cc: linux-kernel, torvalds On 2017-05-14 13:59:22, rdunlap@infradead.org wrote: > On 05/13/17 13:57, Linus Torvalds wrote: > > One thing worth noting - I haven't uploaded diffs or tar-balls for > > this rc. Those should now be automagically generated by kernel.org for > > the rc's, but that also means that they won't be signed by my key. If > > you really care about signing, get the git repo and check the tag. > > > There was some delay (don't know how much), but a bigger problem is > the file(s) locations and (new) directory structure for them. This is intentional to indicate the transient autogenerated nature of these files. They don't exist in the /pub tree and therefore it is misleading to rewrite URLs to place them there. > Can the generated files please be put in the same places that (most or > all) previous releases have used? Not unless there is a convincing reason to do so (and please feel free to provide it, as this is not a final change and can always be undone should the counter-arguments be convincing). Regards, -- Konstantin Ryabitsev Senior Systems Administrator Linux Foundation Collab Projects Montréal, Québec ^ permalink raw reply [flat|nested] 16+ messages in thread
* linux-next: stats (Was: Linux 4.12-rc1) 2017-05-13 20:57 ` Linux 4.12-rc1 Linus Torvalds 2017-05-14 17:59 ` Linux 4.12-rc1 (file locations) Randy Dunlap @ 2017-05-15 13:15 ` Stephen Rothwell 2017-05-15 14:51 ` Sebastian Reichel 1 sibling, 1 reply; 16+ messages in thread From: Stephen Rothwell @ 2017-05-15 13:15 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List Hi all, As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20170502 was the first linux-next after the merge window opened.) Commits in v4.12-rc1 (relative to v4.11): 12920 Commits in next-20170502: 12432 Commits with the same SHA1: 11772 Commits with the same patch_id: 331 (1) Commits with the same subject line: 41 (1) (1) not counting those in the lines above. So commits in -rc1 that were in next-20170502: 12144 93% Some breakdown of the list of extra commits (relative to next-20170502) in -rc1: Top ten first word of commit summary: 143 drm 55 kvm 38 annotate 23 net 20 powerpc 20 ib 14 perf 13 x86 13 arm64 12 target Top ten authors: 39 dhowells@redhat.com 32 rex.zhu@amd.com 24 eric.auger@redhat.com 14 ray.huang@amd.com 14 christian.koenig@amd.com 12 alexander.deucher@amd.com 11 osandov@fb.com 11 idryomov@gmail.com 11 cdall@linaro.org 11 axboe@fb.com Top ten commiters: 132 alexander.deucher@amd.com 105 davem@davemloft.net 38 dhowells@redhat.com 38 axboe@fb.com 37 cdall@linaro.org 31 idryomov@gmail.com 26 torvalds@linux-foundation.org 25 nab@linux-iscsi.org 24 pbonzini@redhat.com 22 mpe@ellerman.id.au There are also 288 commits in next-20170502 that didn't make it into v4.12-rc1. Top ten first word of commit summary: 23 arm 19 mm 18 watchdog 13 rcu 9 srcu 9 rcutorture 9 btrfs 8 rcuperf 8 arm64 7 fault-inject Top ten authors: 45 paulmck@linux.vnet.ibm.com 19 akpm@linux-foundation.org 18 alexandre.belloni@free-electrons.com 15 tglx@linutronix.de 15 bigeasy@linutronix.de 11 peda@axentia.se 9 quwenruo@cn.fujitsu.com 6 olof@lixom.net 6 akinobu.mita@gmail.com 5 kernel@networkimprov.net Some of Andrew's patches are fixes for other patches in his tree (and have been merged into those). Top ten commiters: 66 sfr@canb.auug.org.au 47 paulmck@linux.vnet.ibm.com 34 tglx@linutronix.de 23 linux@roeck-us.net 14 alexandre.belloni@free-electrons.com 11 peda@axentia.se 9 quwenruo@cn.fujitsu.com 8 olof@lixom.net 7 sre@kernel.org 5 mathieu.poirier@linaro.org Those commits by me are from the quilt series (mainly Andrew's mmotm tree). -- Cheers, Stephen Rothwell ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: linux-next: stats (Was: Linux 4.12-rc1) 2017-05-15 13:15 ` linux-next: stats (Was: Linux 4.12-rc1) Stephen Rothwell @ 2017-05-15 14:51 ` Sebastian Reichel 2017-05-15 21:32 ` Stephen Rothwell 0 siblings, 1 reply; 16+ messages in thread From: Sebastian Reichel @ 2017-05-15 14:51 UTC (permalink / raw) To: Stephen Rothwell; +Cc: Linus Torvalds, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 716 bytes --] Hi, On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote: > There are also 288 commits in next-20170502 that didn't make it into > v4.12-rc1. > > [...] > > Top ten commiters: > > 66 sfr@canb.auug.org.au > 47 paulmck@linux.vnet.ibm.com > 34 tglx@linutronix.de > 23 linux@roeck-us.net > 14 alexandre.belloni@free-electrons.com > 11 peda@axentia.se > 9 quwenruo@cn.fujitsu.com > 8 olof@lixom.net > 7 sre@kernel.org > 5 mathieu.poirier@linaro.org Did you compile the list today? I started adding content for 4.13 after Linus tagged v4.12-rc1 and my power-supply for-next branch curently has exactly 7 patches. -- Sebastian [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: linux-next: stats (Was: Linux 4.12-rc1) 2017-05-15 14:51 ` Sebastian Reichel @ 2017-05-15 21:32 ` Stephen Rothwell 2017-05-20 16:33 ` Sebastian Reichel 0 siblings, 1 reply; 16+ messages in thread From: Stephen Rothwell @ 2017-05-15 21:32 UTC (permalink / raw) To: Sebastian Reichel; +Cc: Linus Torvalds, Linux Kernel Mailing List Hi Sebastian, On Mon, 15 May 2017 16:51:08 +0200 Sebastian Reichel <sre@kernel.org> wrote: > > On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote: > > There are also 288 commits in next-20170502 that didn't make it into > > v4.12-rc1. > > > > [...] > > > > Top ten commiters: > > > > 66 sfr@canb.auug.org.au > > 47 paulmck@linux.vnet.ibm.com > > 34 tglx@linutronix.de > > 23 linux@roeck-us.net > > 14 alexandre.belloni@free-electrons.com > > 11 peda@axentia.se > > 9 quwenruo@cn.fujitsu.com > > 8 olof@lixom.net > > 7 sre@kernel.org > > 5 mathieu.poirier@linaro.org > > Did you compile the list today? I started adding content for 4.13 > after Linus tagged v4.12-rc1 and my power-supply for-next branch > curently has exactly 7 patches. As I said above these are commits that were in linux-next on May 2nd but were not in v4.12-rc1: 99484df028dd power: supply: bq27xxx: Add power_supply_battery_info support ac8eb82d2fed power: supply: bq27xxx: Add chip data memory read/write support a66c51d4fe5a power: supply: bq27xxx: Add bulk transfer bus methods 7192174d20dc dt-bindings: power: supply: bq27xxx: Add monitored-battery documentation fb38342a5ae6 power: supply: core: add power_supply_battery_info and API bbdc4f09fe12 devicetree: property-units: Add uWh and uAh units ecc931a585b3 dt-bindings: power: supply: add simple-battery DT binding There can be various reasons that they didn't make it in and, in fact, these are not in yesterday's linux-next either. -- Cheers, Stephen Rothwell ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: linux-next: stats (Was: Linux 4.12-rc1) 2017-05-15 21:32 ` Stephen Rothwell @ 2017-05-20 16:33 ` Sebastian Reichel 0 siblings, 0 replies; 16+ messages in thread From: Sebastian Reichel @ 2017-05-20 16:33 UTC (permalink / raw) To: Stephen Rothwell; +Cc: Linus Torvalds, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 1876 bytes --] Hi Stephen, On Tue, May 16, 2017 at 07:32:09AM +1000, Stephen Rothwell wrote: > On Mon, 15 May 2017 16:51:08 +0200 Sebastian Reichel <sre@kernel.org> wrote: > > On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote: > > > There are also 288 commits in next-20170502 that didn't make it into > > > v4.12-rc1. > > > > > > [...] > > > > > > Top ten commiters: > > > > > > 66 sfr@canb.auug.org.au > > > 47 paulmck@linux.vnet.ibm.com > > > 34 tglx@linutronix.de > > > 23 linux@roeck-us.net > > > 14 alexandre.belloni@free-electrons.com > > > 11 peda@axentia.se > > > 9 quwenruo@cn.fujitsu.com > > > 8 olof@lixom.net > > > 7 sre@kernel.org > > > 5 mathieu.poirier@linaro.org > > > > Did you compile the list today? I started adding content for 4.13 > > after Linus tagged v4.12-rc1 and my power-supply for-next branch > > curently has exactly 7 patches. > > As I said above these are commits that were in linux-next on May 2nd > but were not in v4.12-rc1 oh, I missed that. > 99484df028dd power: supply: bq27xxx: Add power_supply_battery_info support > ac8eb82d2fed power: supply: bq27xxx: Add chip data memory read/write support > a66c51d4fe5a power: supply: bq27xxx: Add bulk transfer bus methods > 7192174d20dc dt-bindings: power: supply: bq27xxx: Add monitored-battery documentation > fb38342a5ae6 power: supply: core: add power_supply_battery_info and API > bbdc4f09fe12 devicetree: property-units: Add uWh and uAh units > ecc931a585b3 dt-bindings: power: supply: add simple-battery DT binding > > There can be various reasons that they didn't make it in and, in fact, > these are not in yesterday's linux-next either. Thanks, I forgot about those when I wrote my mail. The patch author asked me to drop them for 4.12 due to some problems. -- Sebastian [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-05-24 20:14 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <RT-Ticket-40777@linuxfoundation> 2017-05-13 20:57 ` Linux 4.12-rc1 Linus Torvalds 2017-05-14 17:59 ` Linux 4.12-rc1 (file locations) Randy Dunlap 2017-05-15 15:42 ` Linus Torvalds 2017-05-15 15:42 ` [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] " Linus Torvalds via RT 2017-05-15 18:34 ` François Valenduc 2017-05-15 18:34 ` François Valenduc via RT [not found] ` <rt-4.4.0-31767-1494873296-832.40777-6-0@linuxfoundation> 2017-05-15 18:42 ` [Kernel.org Helpdesk " Konstantin Ryabitsev via RT 2017-05-24 18:34 ` Christian Kujau 2017-05-24 18:42 ` Christian Kujau via RT [not found] ` <rt-4.4.0-12250-1495651374-7.40777-6-0@linuxfoundation> 2017-05-24 20:14 ` Konstantin Ryabitsev via RT [not found] ` <rt-4.4.0-31807-1494862968-1551.40777-6-0@linuxfoundation> 2017-05-16 21:22 ` Konstantin Ryabitsev via RT 2017-05-15 18:45 ` Konstantin Ryabitsev via RT 2017-05-15 13:15 ` linux-next: stats (Was: Linux 4.12-rc1) Stephen Rothwell 2017-05-15 14:51 ` Sebastian Reichel 2017-05-15 21:32 ` Stephen Rothwell 2017-05-20 16:33 ` Sebastian Reichel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.