Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1641010 > unrolled thread
| Started by | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| First post | 2017-05-13 23:00 +0200 |
| Last post | 2017-05-20 18:40 +0200 |
| Articles | 16 — 10 participants |
Back to article view | Back to linux.kernel
Linux 4.12-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-13 23:00 +0200
Re: Linux 4.12-rc1 (file locations) Randy Dunlap <rdunlap@infradead.org> - 2017-05-14 20:10 +0200
Re: Linux 4.12-rc1 (file locations) Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-15 17:50 +0200
[Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations) "Linus Torvalds via RT" <kernel-helpdesk@rt.linuxfoundation.org> - 2017-05-15 18:00 +0200
Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations) "François Valenduc via RT" <kernel-helpdesk@rt.linuxfoundation.org> - 2017-05-15 20:40 +0200
Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations) François Valenduc <francoisvalenduc@gmail.com> - 2017-05-15 20:40 +0200
[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) "Konstantin Ryabitsev via RT" <kernel-helpdesk@rt.linuxfoundation.org> - 2017-05-15 20:50 +0200
Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) "Christian Kujau via RT" <kernel-helpdesk@rt.linuxfoundation.org> - 2017-05-24 20:50 +0200
Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) Christian Kujau <lists@nerdbynature.de> - 2017-05-24 20:50 +0200
[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) "Konstantin Ryabitsev via RT" <kernel-helpdesk@rt.linuxfoundation.org> - 2017-05-24 22:20 +0200
[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) "Konstantin Ryabitsev via RT" <kernel-helpdesk@rt.linuxfoundation.org> - 2017-05-16 23:30 +0200
[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) "Konstantin Ryabitsev via RT" <kernel-helpdesk@rt.linuxfoundation.org> - 2017-05-15 20:50 +0200
linux-next: stats (Was: Linux 4.12-rc1) Stephen Rothwell <sfr@canb.auug.org.au> - 2017-05-15 15:20 +0200
Re: linux-next: stats (Was: Linux 4.12-rc1) Sebastian Reichel <sre@kernel.org> - 2017-05-15 17:00 +0200
Re: linux-next: stats (Was: Linux 4.12-rc1) Stephen Rothwell <sfr@canb.auug.org.au> - 2017-05-15 23:40 +0200
Re: linux-next: stats (Was: Linux 4.12-rc1) Sebastian Reichel <sre@kernel.org> - 2017-05-20 18:40 +0200
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2017-05-13 23:00 +0200 |
| Subject | Linux 4.12-rc1 |
| Message-ID | <tGMiR-jQ-5@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Randy Dunlap <rdunlap@infradead.org> |
|---|---|
| Date | 2017-05-14 20:10 +0200 |
| Subject | Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tH67U-4Wy-11@gated-at.bofh.it> |
| In reply to | #1641010 |
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
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2017-05-15 17:50 +0200 |
| Subject | Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tHqpY-1AI-29@gated-at.bofh.it> |
| In reply to | #1641172 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Linus Torvalds via RT" <kernel-helpdesk@rt.linuxfoundation.org> |
|---|---|
| Date | 2017-05-15 18:00 +0200 |
| Subject | [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tHqzF-1DW-27@gated-at.bofh.it> |
| In reply to | #1641835 |
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
[toc] | [prev] | [next] | [standalone]
| From | "François Valenduc via RT" <kernel-helpdesk@rt.linuxfoundation.org> |
|---|---|
| Date | 2017-05-15 20:40 +0200 |
| Subject | Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tHt4t-3gB-3@gated-at.bofh.it> |
| In reply to | #1641853 |
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
[toc] | [prev] | [next] | [standalone]
| From | François Valenduc <francoisvalenduc@gmail.com> |
|---|---|
| Date | 2017-05-15 20:40 +0200 |
| Subject | Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tHt4t-3gB-5@gated-at.bofh.it> |
| In reply to | #1641853 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Konstantin Ryabitsev via RT" <kernel-helpdesk@rt.linuxfoundation.org> |
|---|---|
| Date | 2017-05-15 20:50 +0200 |
| Subject | [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tHte9-3jL-9@gated-at.bofh.it> |
| In reply to | #1641969 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Christian Kujau via RT" <kernel-helpdesk@rt.linuxfoundation.org> |
|---|---|
| Date | 2017-05-24 20:50 +0200 |
| Subject | Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tKJw5-5Wg-3@gated-at.bofh.it> |
| In reply to | #1641973 |
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
[toc] | [prev] | [next] | [standalone]
| From | Christian Kujau <lists@nerdbynature.de> |
|---|---|
| Date | 2017-05-24 20:50 +0200 |
| Subject | Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tKJw5-5Wg-5@gated-at.bofh.it> |
| In reply to | #1641973 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Konstantin Ryabitsev via RT" <kernel-helpdesk@rt.linuxfoundation.org> |
|---|---|
| Date | 2017-05-24 22:20 +0200 |
| Subject | [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tKKVb-6Ww-7@gated-at.bofh.it> |
| In reply to | #1649862 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Konstantin Ryabitsev via RT" <kernel-helpdesk@rt.linuxfoundation.org> |
|---|---|
| Date | 2017-05-16 23:30 +0200 |
| Subject | [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tHScy-2wE-11@gated-at.bofh.it> |
| In reply to | #1641835 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Konstantin Ryabitsev via RT" <kernel-helpdesk@rt.linuxfoundation.org> |
|---|---|
| Date | 2017-05-15 20:50 +0200 |
| Subject | [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations) |
| Message-ID | <tHte9-3jL-1@gated-at.bofh.it> |
| In reply to | #1641172 |
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
[toc] | [prev] | [next] | [standalone]
| From | Stephen Rothwell <sfr@canb.auug.org.au> |
|---|---|
| Date | 2017-05-15 15:20 +0200 |
| Subject | linux-next: stats (Was: Linux 4.12-rc1) |
| Message-ID | <tHo4N-fL-1@gated-at.bofh.it> |
| In reply to | #1641010 |
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
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2017-05-15 17:00 +0200 |
| Subject | Re: linux-next: stats (Was: Linux 4.12-rc1) |
| Message-ID | <tHpDz-12A-17@gated-at.bofh.it> |
| In reply to | #1641647 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Stephen Rothwell <sfr@canb.auug.org.au> |
|---|---|
| Date | 2017-05-15 23:40 +0200 |
| Subject | Re: linux-next: stats (Was: Linux 4.12-rc1) |
| Message-ID | <tHvSG-51z-15@gated-at.bofh.it> |
| In reply to | #1641777 |
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
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2017-05-20 18:40 +0200 |
| Subject | Re: linux-next: stats (Was: Linux 4.12-rc1) |
| Message-ID | <tJfA5-3RZ-1@gated-at.bofh.it> |
| In reply to | #1642077 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web