LKML Archive on lore.kernel.org help / color / Atom feed

* Linux 4.19-rc4 released, an apology, and a maintainership note @ 2018-09-16 19:22 Linus Torvalds 2018-09-16 21:42 ` [...] " Adam Borowski ` (9 more replies) 0 siblings, 10 replies; 24+ messages in thread From: Linus Torvalds @ 2018-09-16 19:22 UTC (permalink / raw) To: Linux Kernel Mailing List [ So this email got a lot longer than I initially thought it would get, but let's start out with the "regular Sunday release" part ] Another week, another rc. Nothing particularly odd stands out on the technical side in the kernel updates for last week - rc4 looks fairly average in size for this stage in the release cycle, and all the other statistics look pretty normal too. We've got roughly two thirds driver fixes (gpu and networking look to be the bulk of it, but there's smaller changes all over in various driver subsystems), with the rest being the usual mix: core networking, perf tooling updates, arch updates, Documentation, some filesystem, vm and minor core kernel fixes. So it's all fairly small and normal for this stage. As usual, I'm appending the shortlog at the bottom for people who want to get an overview of the details without actually having to go dig in the git tree. The one change that stands out and merits mention is the code of conduct addition... [ And here comes the other, much longer, part... ] Which brings me to the *NOT* normal part of the last week: the discussions (both in public mainly on the kernel summit discussion lists and then a lot in various private communications) about maintainership and the kernel community. Some of that discussion came about because of me screwing up my scheduling for the maintainer summit where these things are supposed to be discussed. And don't get me wrong. It's not like that discussion itself is in any way new to this week - we've been discussing maintainership and community for years. We've had lots of discussions both in private and on mailing lists. We have regular talks at conferences - again, both the "public speaking" kind and the "private hallway track" kind. No, what was new last week is really my reaction to it, and me being perhaps introspective (you be the judge). There were two parts to that. One was simply my own reaction to having screwed up my scheduling of the maintainership summit: yes, I was somewhat embarrassed about having screwed up my calendar, but honestly, I was mostly hopeful that I wouldn't have to go to the kernel summit that I have gone to every year for just about the last two decades. Yes, we got it rescheduled, and no, my "maybe you can just do it without me there" got overruled. But that whole situation then started a whole different kind of discussion. And kind of incidentally to that one, the second part was that I realized that I had completely mis-read some of the people involved. This is where the "look yourself in the mirror" moment comes in. So here we are, me finally on the one hand realizing that it wasn't actually funny or a good sign that I was hoping to just skip the yearly kernel summit entirely, and on the other hand realizing that I really had been ignoring some fairly deep-seated feelings in the community. It's one thing when you can ignore these issues. Usually it’s just something I didn't want to deal with. This is my reality. I am not an emotionally empathetic kind of person and that probably doesn't come as a big surprise to anybody. Least of all me. The fact that I then misread people and don't realize (for years) how badly I've judged a situation and contributed to an unprofessional environment is not good. This week people in our community confronted me about my lifetime of not understanding emotions. My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry. The above is basically a long-winded way to get to the somewhat painful personal admission that hey, I need to change some of my behavior, and I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely. I am going to take time off and get some assistance on how to understand people’s emotions and respond appropriately. Put another way: When asked at conferences, I occasionally talk about how the pain-points in kernel development have generally not been about the _technical_ issues, but about the inflection points where development flow and behavior changed. These pain points have been about managing the flow of patches, and often been associated with big tooling changes - moving from making releases with "patches and tar-balls" (and the _very_ painful discussions about how "Linus doesn't scale" back 15+ years ago) to using BitKeeper, and then to having to write git in order to get past the point of that no longer working for us. We haven't had that kind of pain-point in about a decade. But this week felt like that kind of pain point to me. To tie this all back to the actual 4.19-rc4 release (no, really, this _is_ related!) I actually think that 4.19 is looking fairly good, things have gotten to the "calm" period of the release cycle, and I've talked to Greg to ask him if he'd mind finishing up 4.19 for me, so that I can take a break, and try to at least fix my own behavior. This is not some kind of "I'm burnt out, I need to just go away" break. I'm not feeling like I don't want to continue maintaining Linux. Quite the reverse. I very much *do* want to continue to do this project that I've been working on for almost three decades. This is more like the time I got out of kernel development for a while because I needed to write a little tool called "git". I need to take a break to get help on how to behave differently and fix some issues in my tooling and workflow. And yes, some of it might be "just" tooling. Maybe I can get an email filter in place so at when I send email with curse-words, they just won't go out. Because hey, I'm a big believer in tools, and at least _some_ problems going forward might be improved with simple automation. I know when I really look “myself in the mirror” it will be clear it's not the only change that has to happen, but hey... You can send me suggestions in email. I look forward to seeing you at the Maintainer Summit. Linus --- Aaron Knister (1): IB/ipoib: Avoid a race condition between start_xmit and cm_rep_handler AceLan Kao (1): HID: i2c-hid: Fix flooded incomplete report after S3 on Rayd touchscreen Adrian Hunter (1): perf tools: Fix maps__find_symbol_by_name() Ahmed S. Darwish (1): staging: gasket: TODO: re-implement using UIO Alan Stern (1): USB: net2280: Fix erroneous synchronization change Alexander Usyskin (1): mei: ignore not found client in the enumeration Amir Goldstein (6): ovl: respect FIEMAP_FLAG_SYNC flag ovl: fix GPF in swapfile_activate of file from overlayfs over xfs Documentation/filesystems: update documentation of file_operations vfs: add the fadvise() file operation vfs: implement readahead(2) using POSIX_FADV_WILLNEED ovl: add ovl_fadvise() Andreas Bosch (1): HID: intel-ish-hid: Enable Sunrise Point-H ish driver Andreas Kemnade (1): mmc: omap_hsmmc: fix wakeirq handling on removal Andrew Murray (1): asm-generic: io: Fix ioport_map() for !CONFIG_GENERIC_IOMAP && CONFIG_INDIRECT_PIO Anton Vasilyev (1): usb: gadget: fotg210-udc: Fix memory leak of fotg210->ep[i] Anurag Kumar Vulisha (1): usb: host: xhci-plat: Iterate over parent nodes for finding quirks Arnaldo Carvalho de Melo (7): perf tools: Streamline bpf examples and headers installation tools headers uapi: Update tools's copy of linux/perf_event.h tools headers uapi: Update tools's copy of asm-generic/unistd.h tools headers uapi: Update tools's copy of drm/drm.h tools headers uapi: Update tools's copies of kvm headers tools headers uapi: Update tools's copy of linux/vhost.h tools headers uapi: Update tools's copy of linux/if_link.h Arnd Bergmann (2): staging: wilc1000: revert "fix TODO to compile spi and sdio components in single module" usb: dwc3: of-simple: avoid unused function warnings Artemy Kovalyov (1): IB/core: Release object lock if destroy failed Ben Hutchings (3): USB: yurex: Fix buffer over-read in yurex_write() USB: yurex: Check for truncation in yurex_read() locking/lockdep: Delete unnecessary #include Ben Skeggs (8): drm/nouveau: fix oops in client init failure path drm/nouveau/mmu: don't attempt to dereference vmm without valid instance pointer drm/nouveau/TBDdevinit: don't fail when PMU/PRE_OS is missing from VBIOS drm/nouveau/disp: remove unused struct member drm/nouveau/disp: move eDP panel power handling drm/nouveau/disp: fix DP disable race drm/nouveau/disp/gm200-: enforce identity-mapped SOR assignment for LVDS/eDP panels drm/nouveau/devinit: fix warning when PMU/PRE_OS is missing Benjamin Fair (1): ipmi: kcs_bmc: don't change device name Benjamin Tissoires (2): HID: multitouch: fix Elan panels with 2 input modes declaration HID: core: fix grouping by application Bin Yang (1): pstore: Fix incorrect persistent ram buffer mapping Boris Ostrovsky (1): x86/EISA: Don't probe EISA bus for Xen PV guests Borislav Petkov (1): jump_label: Fix typo in warning message Bruno Meirelles Herrera (1): usb: dwc2: Fix call location of dwc2_check_core_endianness Bryant G. Ly (1): misc: ibmvsm: Fix wrong assignment of return code Chris Phlipot (2): perf util: Fix bad memory access in trace info. perf event-parse: Use fixed size string for comms Chris Wilson (1): drm/i915/overlay: Allocate physical registers from stolen Christian König (2): drm/amdgpu: fix amdgpu_mn_unlock() in the CS error path drm/amdgpu: fix error handling in amdgpu_cs_user_fence_chunk Chunfeng Yun (2): usb: mtu3: fix error of xhci port id when enable U3 dual role usb: xhci: fix interrupt transfer error happened on MTK platforms Colin Ian King (1): locking/ww_mutex: Fix spelling mistake "cylic" -> "cyclic" Cong Wang (6): tipc: orphan sock in tipc_release() tipc: call start and done ops directly in __tipc_nl_compat_dumpit() net_sched: properly cancel netlink dump on failure netfilter: xt_hashlimit: use s->file instead of s->private rds: fix two RCU related problems tipc: check return value of __tipc_dump_start() Corey Minyard (3): ipmi: Rework SMI registration failure ipmi: Move BT capabilities detection to the detect call ipmi: Fix I2C client removal in the SSIF driver Dan Carpenter (4): cifs: prevent integer overflow in nxt_dir_entry() CIFS: fix wrapping bugs in num_entries() cifs: integer overflow in in SMB2_ioctl() cifs: read overflow in is_valid_oplock_break() Daniel Jurgens (1): net/mlx5: Consider PCI domain in search for next dev Daniel Vetter (1): staging/fbtft: Update TODO and mailing lists Davide Caratti (1): net/sched: fix memory leak in act_tunnel_key_init() Dennis Dalessandro (2): PCI: Fix faulty logic in pci_reset_bus() IB/hfi1,PCI: Allow bus reset while probing Emily Deng (1): drm/amdgpu: move PSP init prior to IH in gpu reset Felix Kuehling (1): PCI: Fix enabling of PASID on RC integrated endpoints Florian Westphal (5): netfilter: xt_checksum: ignore gso skbs netfilter: conntrack: place 'new' timeout in first location too netfilter: nf_tables: rework ct timeout set support netfilter: kconfig: nat related expression depend on nftables core netfilter: conntrack: reset tcp maxwin on re-register Gao Xiang (2): Revert "staging: erofs: disable compiling temporarile" staging: erofs: rename superblock flags (MS_xyz -> SB_xyz) Greg Kroah-Hartman (1): Code of Conduct: Let's revamp it. Guenter Roeck (2): riscv: Do not overwrite initrd_start and initrd_end x86/efi: Load fixmap GDT in efi_call_phys_epilog() before setting %cr3 Gustavo A. R. Silva (4): ipmi: Fix NULL pointer dereference in ssif_probe HID: core: fix NULL pointer dereference switchtec: Fix Spectre v1 vulnerability misc: hmc6352: fix potential Spectre v1 Haishuang Yan (2): erspan: return PACKET_REJECT when the appropriate tunnel is not found erspan: fix error handling for erspan tunnel Hans de Goede (3): HID: sensor-hub: Restore fixup for Lenovo ThinkPad Helix 2 sensor hub report staging: vboxvideo: Fix IRQs no longer working staging: vboxvideo: Change address of scanout buffer on page-flip Harry Mallon (1): HID: hid-saitek: Add device ID for RAT 7 Contagion Hauke Mehrtens (1): MIPS: lantiq: dma: add dev pointer Heinz Mauelshagen (5): dm raid: fix reshape race on small devices dm raid: fix stripe adding reshape deadlock dm raid: fix rebuild of specific devices by updating superblock dm raid: fix RAID leg rebuild errors dm raid: bump target version, update comments and documentation Hisao Tanabe (1): perf evsel: Fix potential null pointer dereference in perf_evsel__new_idx() Huang Shijie (1): dmaengine: mic_x100_dma: use devm_kzalloc to fix an issue Huy Nguyen (1): net/mlx5: Check for error in mlx5_attach_interface Imre Deak (1): drm/i915/bdw: Increase IPS disable timeout to 100ms Ingo Franzki (1): s390/crypto: Fix return code checking in cbc_paes_crypt() Jacek Tomaka (1): perf/x86/intel: Add support/quirk for the MISPREDICT bit on Knights Landing CPUs Jack Morgenstein (2): net/mlx5: Fix use-after-free in self-healing flow net/mlx5: Fix debugfs cleanup in the device init/remove flow James Morse (1): arm64: kernel: arch_crash_save_vmcoreinfo() should depend on CONFIG_CRASH_CORE Jann Horn (1): RDMA/ucma: check fd type in ucma_migrate_id() Jens Axboe (2): blk-cgroup: increase number of supported policies null_blk: fix zoned support for non-rq based operation Jia-Ju Bai (3): usb: host: u132-hcd: Fix a sleep-in-atomic-context bug in u132_get_frame() usb: misc: uss720: Fix two sleep-in-atomic-context bugs usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt() Jiada Wang (1): sched/debug: Fix potential deadlock when writing to sched_features Jiri Olsa (5): perf tests: Add breakpoint modify tests perf/hw_breakpoint: Modify breakpoint even if the new attr has disabled set perf/hw_breakpoint: Remove superfluous bp->attr.disabled = 0 perf/hw_breakpoint: Enable breakpoint in modify_user_hw_breakpoint perf/hw_breakpoint: Simplify breakpoint enable in perf_event_modify_breakpoint Joao Pinto (1): MAINTAINERS: Add Gustavo Pimentel as DesignWare PCI maintainer Joe Thornber (1): dm thin metadata: try to avoid ever aborting transactions Joerg Roedel (1): Revert "x86/mm/legacy: Populate the user page-table with user pgd's" Johan Hovold (3): USB: serial: io_ti: fix array underflow in completion handler USB: serial: ti_usb_3410_5052: fix array underflow in completion handler mmc: meson-mx-sdio: fix OF child-node lookup John Hubbard (1): mei: fix use-after-free in mei_cl_write Josh Abraham (1): xen: fix GCC warning and remove duplicate EVTCHN_ROW/EVTCHN_COL usage Juergen Gross (2): xen/netfront: fix waiting for xenbus state change x86/xen: Disable CPU0 hotplug for Xen PV Julian Wiedmann (6): net/af_iucv: drop inbound packets with invalid flags net/af_iucv: fix skb handling on HiperTransport xmit error net/iucv: declare iucv_path_table_empty() as static s390/qeth: indicate error when netdev allocation fails s390/qeth: switch on SG by default for IQD devices s390/qeth: don't dump past end of unknown HW header K. Y. Srinivasan (1): Tools: hv: Fix a bug in the key delete code Kai-Heng Feng (2): HID: i2c-hid: Don't reset device upon system resume r8169: Clear RTL_FLAG_TASK_*_PENDING when clearing RTL_FLAG_TASK_ENABLED Keith Busch (1): PCI: pciehp: Fix hot-add vs powerfault detection order Kim Phillips (2): perf arm64: Fix include path for asm-generic/unistd.h perf annotate: Fix parsing aarch64 branch instructions after objdump update Kristian Evensen (1): qmi_wwan: Support dynamic config on Quectel EP06 Kuninori Morimoto (1): ethernet: renesas: convert to SPDX identifiers Leon Romanovsky (1): RDMA/mlx4: Ensure that maximal send/receive SGE less than supported by HW Linus Torvalds (2): mm: get rid of vmacache_flush_all() entirely Linux 4.19-rc4 Lorenzo Bianconi (1): iio: imu: st_lsm6dsx: take into account ts samples in wm configuration Louis Peens (1): nfp: flower: reject tunnel encap with ipv6 outer headers for offloading Lyude Paul (13): drm/nouveau/drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend() drm/nouveau/drm/nouveau: Fix deadlock with fb_helper with async RPM requests drm/nouveau/drm/nouveau: Use pm_runtime_get_noresume() in connector_detect() drm/nouveau: Fix deadlocks in nouveau_connector_detect() drm/nouveau: Remove useless poll_enable() call in switcheroo_set_state() drm/nouveau: Remove useless poll_disable() call in switcheroo_set_state() drm/nouveau: Remove useless poll_enable() call in drm_load() drm/nouveau: Only write DP_MSTM_CTRL when needed drm/nouveau: Reset MST branching unit before enabling drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early drm/nouveau/drm/nouveau: Don't forget to cancel hpd_work on suspend/unload drm/nouveau: Fix nouveau_connector_ddc_detect() Maciej S. Szmigiero (1): r8169: set TxConfig register after TX / RX is enabled, just like RxConfig Marek Marczykowski-Górecki (1): xen/balloon: add runtime control for scrubbing ballooned out pages Martin Liška (1): perf annotate: Properly interpret indirect call Martin Schwidefsky (1): s390/zcrypt: remove VLA usage from the AP bus Martin Willi (1): netfilter: xt_cluster: add dependency on conntrack module Masahiro Yamada (1): xtensa: remove unnecessary KBUILD_SRC ifeq conditional Mathias Nyman (3): xhci: Fix use after free for URB cancellation on a reallocated endpoint usb: Don't die twice if PCI xhci host is not responding in resume usb: Avoid use-after-free by flushing endpoints early in usb_set_interface() Matt Ranostay (1): Revert "iio: temperature: maxim_thermocouple: add MAX31856 part" Max Filippov (2): xtensa: ISS: don't allocate memory in platform_setup xtensa: enable SG chaining in Kconfig Maxence Duprès (1): USB: add quirk for WORLDE Controller KS49 or Prodipe MIDI 49C USB controller Michal 'vorner' Vaner (1): netfilter: nfnetlink_queue: Solve the NFQUEUE/conntrack clash for NF_REPEAT Michal Hocko (1): xen/gntdev: fix up blockable calls to mn_invl_range_start Miguel Ojeda (1): arm64: jump_label.h: use asm_volatile_goto macro instead of "asm goto" Mika Westerberg (1): Revert "PCI: Add ACS quirk for Intel 300 series" Mike Christie (1): scsi: iscsi: target: Fix conn_ops double free Miklos Szeredi (1): ovl: fix oopses in ovl_fill_super() failure paths Mikulas Patocka (2): dm verity: fix crash on bufio buffer that was allocated with vmalloc dm: disable CRYPTO_TFM_REQ_MAY_SLEEP to fix a GFP_KERNEL recursion deadlock Minchan Kim (1): android: binder: fix the race mmap and alloc_new_buf_locked Netanel Belgazal (7): net: ena: fix surprise unplug NULL dereference kernel crash net: ena: fix driver when PAGE_SIZE == 64kB net: ena: fix device destruction to gracefully free resources net: ena: fix potential double ena_destroy_device() net: ena: fix missing lock during device destruction net: ena: fix missing calls to READ_ONCE net: ena: fix incorrect usage of memory barriers Nicholas Piggin (3): tty: hvc: hvc_poll() fix read loop hang tty: hvc: hvc_poll() fix read loop batching tty: hvc: hvc_write() fix break condition Nilesh Javali (1): scsi: qedi: Add the CRC size within iSCSI NVM image Olaf Hering (1): xen: avoid crash in disable_hotplug_cpu Oliver Neukum (2): usb: uas: add support for more quirk flags Revert "cdc-acm: implement put_char() and flush_chars()" Pablo Neira Ayuso (2): netfilter: conntrack: timeout interface depend on CONFIG_NF_CONNTRACK_TIMEOUT netfilter: cttimeout: ctnl_timeout_find_get() returns incorrect pointer to type Parav Pandit (2): RDMA/uverbs: Fix error cleanup path of ib_uverbs_add_one() RDMA/cma: Protect cma dev list with lock Paul Burton (1): pinctrl: ingenic: Fix group & function error checking Paulo Zanoni (1): tracing/Makefile: Fix handling redefinition of CC_FLAGS_FTRACE Peter Zijlstra (1): perf/UAPI: Clearly mark __PERF_SAMPLE_CALLCHAIN_EARLY as internal use Petr Machata (1): mlxsw: spectrum_buffers: Set up a dedicated pool for BUM traffic Petr Mladek (1): Revert "printk: make sure to print log on console." Petr Oros (1): be2net: Fix memory leak in be_cmd_get_profile_config() Pieter Jansen van Vuuren (1): nfp: flower: fix vlan match by checking both vlan id and vlan pcp Raed Salem (1): net/mlx5: E-Switch, Fix memory leak when creating switchdev mode FDB tables Randy Dunlap (9): usb/dwc3/gadget: fix kernel-doc parameter warning usb: typec: fix kernel-doc parameter warning usb/typec: fix kernel-doc notation warning for typec_match_altmode linux/mod_devicetable.h: fix kernel-doc missing notation for typec_device_id sched/fair: Fix kernel-doc notation warning x86/doc: Fix Documentation/x86/earlyprintk.txt arch/hexagon: fix kernel/dma.c build warning hexagon: modify ffs() and fls() to return int x86/APM: Fix build warning when PROC_FS is not enabled Richard Fitzgerald (1): pinctrl: madera: Fix possible NULL pointer with pdata config Rishabh Bhatnagar (1): firmware: Fix security issue with request_firmware_into_buf() Rob Herring (1): of: fix phandle cache creation for DTs with no phandles Roi Dayan (2): net/mlx5: Fix not releasing read lock when adding flow rules net/mlx5: Fix possible deadlock from lockdep when adding fte to fg Saeed Mahameed (1): net/mlx5e: Ethtool steering, fix udp source port value Sagi Grimberg (1): nvmet-rdma: fix possible bogus dereference under heavy load Sandipan Das (1): perf probe powerpc: Ignore SyS symbols irrespective of endianness Sasha Levin (3): tools/lib/lockdep: Update Sasha Levin email to MSFT tools/lib/lockdep: Add empty nmi.h tools/lib/lockdep: Add dummy task_struct state member Sean O'Brien (1): HID: add support for Apple Magic Keyboards Somnath Kotur (1): bnxt_re: Fix couple of memory leaks that could lead to IOMMU call traces Srikar Dronamraju (1): sched/topology: Set correct NUMA topology type Stefan Agner (2): HID: input: fix leaking custom input node name HID: core: fix memory leak on probe Stefan Metzmacher (1): fs/cifs: require sha512 Stefan Wahren (1): net: qca_spi: Fix race condition in spi transfers Stephen Boyd (1): pinctrl: msm: Really mask level interrupts to prevent latching Stephen Hemminger (1): vmbus: don't return values for uninitalized channels Stephen Rothwell (1): fs/cifs: suppress a string overflow warning Steve Muckle (1): sched/fair: Fix vruntime_normalized() for remote non-migration wakeup Steve Wise (1): iw_cxgb4: only allow 1 flush on user qps Taehee Yoo (2): netfilter: nf_tables: release chain in flushing set ip: frags: fix crash in ip_do_fragment() Tao Zhou (1): drm/amdgpu: Fix SDMA hang in prt mode v2 Tariq Toukan (2): net/mlx5: Use u16 for Work Queue buffer fragment size net/mlx5: Use u16 for Work Queue buffer strides offset Tejun Heo (1): MAINTAINERS: Make Dennis the percpu tree maintainer Thomas Hellstrom (1): locking/mutex: Fix mutex debug call and ww_mutex documentation Tim Anderson (1): USB: Add quirk to support DJI CineSSD Todd Poynor (1): MAINTAINERS: Switch a maintainer for drivers/staging/gasket Tomas Winkler (2): mei: bus: fix hw module get/put balance mei: bus: need to unlink client before freeing Trond Myklebust (5): NFSv4: Fix a tracepoint Oops in initiate_file_draining() pNFS: Ensure we return the error if someone kills a waiting layoutget NFSv4: Fix a tracepoint Oops in initiate_file_draining() NFSv4.1 fix infinite loop on I/O. NFS: Don't open code clearing of delegation state Tyrel Datwyler (1): MAINTAINERS: Add entries for PPC64 RPA PCI hotplug drivers Vakul Garg (1): net/tls: Set count of SG entries if sk_alloc_sg returns -ENOSPC Vincent Guittot (3): sched/pelt: Fix update_blocked_averages() for RT and DL classes sched/fair: Fix scale_rt_capacity() for SMT sched/fair: Fix load_balance redo for !imbalance Vincent Pelletier (1): scsi: iscsi: target: Set conn->sess to NULL when iscsi_login_set_conn_values fails Vincent Whitchurch (1): tcp: really ignore MSG_ZEROCOPY if no SO_ZEROCOPY Vitaly Kuznetsov (1): xen/manage: don't complain about an empty value in control/sysrq node Wei Yongjun (2): usb: dwc3: pci: Fix return value check in dwc3_byt_enable_ulpi_refclock() fpga: dfl: fme: fix return value check in in pr_mgmt_init() Weinan Li (1): drm/i915/gvt: Fix the incorrect length of child_device_config issue Wenjia Zhang (1): s390/qeth: use vzalloc for QUERY OAT buffer Willem de Bruijn (1): tcp: rate limit synflood warnings further Yabin Cui (1): perf/core: Force USER_DS when recording user stack data Yoshihiro Shimoda (2): usb: gadget: udc: renesas_usb3: fix maxpacket size of ep0 usb: Change usb_of_get_companion_dev() place to usb/common Yue Haibing (1): netfilter: conntrack: remove duplicated include from nf_conntrack_proto_udp.c Zhenyu Wang (1): drm/i915/gvt: Fix life cycle reference on KVM mm ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: [...] an apology, and a maintainership note 2018-09-16 19:22 Linux 4.19-rc4 released, an apology, and a maintainership note Linus Torvalds @ 2018-09-16 21:42 ` Adam Borowski 2018-09-16 23:59 ` Moritz Obermeier 2018-09-17 0:18 ` Linux 4.19-rc4 released, " Rene Herman ` (8 subsequent siblings) 9 siblings, 1 reply; 24+ messages in thread From: Adam Borowski @ 2018-09-16 21:42 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List On Sun, Sep 16, 2018 at 12:22:43PM -0700, Linus Torvalds wrote: > This is my reality. I am not an emotionally empathetic kind of person > and that probably doesn't come as a big surprise to anybody. Least of > all me. The fact that I then misread people and don't realize (for > years) how badly I've judged a situation and contributed to an > unprofessional environment is not good. > > This week people in our community confronted me about my lifetime of > not understanding emotions. My flippant attacks in emails have been > both unprofessional and uncalled for. Especially at times when I made > it personal. In my quest for a better patch, this made sense to me. > I know now this was not OK and I am truly sorry. > > The above is basically a long-winded way to get to the somewhat > painful personal admission that hey, I need to change some of my > behavior, and I want to apologize to the people that my personal > behavior hurt and possibly drove away from kernel development > entirely. Despite me being just among bottom-rung popcorn of kernel contributors, let me says this: No. Just no. You're so successful because you're one of few people who don't waste time beating around the bush. You call a spade a spade instead of polite "professional" bullshit. You often use rude words, but you don't do so without a reason. IMO your most striking quality is not technical ability (pretty high...) but the ratio of times you open your mouth to the times you're right. And even if you're not right, you don't take offense at getting corrected and immediately admit someone else was right. Sure, there are cases when both choices are right, but your approach avoids wasting time making a decision. For example: recently, you forced disabling string truncation warnings despite many people feeling otherwise. I for one believe GCC's warnings even though sounding bogus are good for eliminating strncpy -- what I would have done would be giving it an aliased version named "fixedfieldncpy" or such that disables the warning, and fixing the whole rest. But what you did instead deprioritizes the issue: the kernel doesn't work any worse than it did with gcc-7, thus there are indeed more urgent matters elsewhere. So even if I don't fully agree with you, you are the boss and as long as your version is acceptable, let's stick to it. And, it's _you_ who has proven merit, not me. > I am going to take time off and get some assistance on how to > understand people’s emotions and respond appropriately. > > Put another way: When asked at conferences, I occasionally talk about > how the pain-points in kernel development have generally not been > about the _technical_ issues, but about the inflection points where > development flow and behavior changed. Too many projects get detracted by prolonged crap about social things, don't let this pull you down. There's a problem when people _without merit_ are rude -- those indeed need to get a spanking. A spanking not ADHD meds. Short and to the point, letting them learn. But you, you _earned_ the right to be rude to get your point across. I watched a video about you getting shamed on a DebConf because of breaching some "code of conduct" by using a naughty word. I didn't like that and believe it was you who was right (I don't recall the details though). > I've talked to Greg to ask him if he'd mind finishing up 4.19 for me, so > that I can take a break, and try to at least fix my own behavior. > > This is not some kind of "I'm burnt out, I need to just go away" > break. I'm not feeling like I don't want to continue maintaining > Linux. Quite the reverse. I very much *do* want to continue to do > this project that I've been working on for almost three decades. > > This is more like the time I got out of kernel development for a while > because I needed to write a little tool called "git". I need to take > a break to get help on how to behave differently and fix some issues > in my tooling and workflow. You do deserve a vacation. By all means, do take a break and let the community rehearse for "Linus got mauled by a bear". But we want you back. > And yes, some of it might be "just" tooling. Maybe I can get an email > filter in place so at when I send email with curse-words, they just > won't go out. Because hey, I'm a big believer in tools, and at least > _some_ problems going forward might be improved with simple > automation. Please don't. When you use curse words, they're _warranted_. They're a tool which, in my opinion, you don't overuse. And it's fun to listen to a true master of words. An example: how many pages would https://lkml.org/lkml/2016/8/2/2062 take to say politely yet get the same effect? > I know when I really look “myself in the mirror” it will be clear it's > not the only change that has to happen, but hey... You can send me > suggestions in email. When you look yourself in the mirror, I want you to see that guy who codes in a bathrobe instead of a sweet-talking lying politician. Being honest means sometimes saying non-nice things. Meow! -- Don't be racist. White, amber or black, all beers should be judged based solely on their merits. Heck, even if occasionally a cider applies for a beer's job, why not? On the other hand, mass-produced lager is not a race. ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: [...] an apology, and a maintainership note 2018-09-16 21:42 ` [...] " Adam Borowski @ 2018-09-16 23:59 ` Moritz Obermeier 0 siblings, 0 replies; 24+ messages in thread From: Moritz Obermeier @ 2018-09-16 23:59 UTC (permalink / raw) To: linux-kernel > When you look yourself in the mirror, I want you to see that guy who codes > in a bathrobe instead of a sweet-talking lying politician. This is why we need more empathy. There is no need for you to decide what Linus sees once he looks into the mirror. You are projecting your own thoughts and emotions onto him. > Being honest means sometimes saying non-nice things. Also I don't think being honest and being nice are mutually exclusive. If someone does something in a bad way, it is actually nice to point that out. But cursing is not really needed for this. In my experience cursing is an indication that the mind is not calm, and therefore one is not making the best possible decisions - which of course results in an not optimal outcome. @Linus: I think it is a very wise decision to take some time off for empathy training. If your subconscious told you to avoid the summit, it is smart to figure out where this comes from. I personally have found mindfulness meditation to be a very helpful tool in becoming more empathetic, but I am sure you are able to achieve your goal without my humble input. I admire your work. Kind Regards, Moritz ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: [...] an apology, and a maintainership note 2018-09-16 19:22 Linux 4.19-rc4 released, an apology, and a maintainership note Linus Torvalds 2018-09-16 21:42 ` [...] " Adam Borowski 2018-09-17 0:18 ` Linux 4.19-rc4 released, " Rene Herman @ 2018-09-17 0:20 ` Andy Isaacson 2018-09-17 0:23 ` Linux 4.19-rc4 released, " Rene Herman ` (6 subsequent siblings) 9 siblings, 0 replies; 24+ messages in thread From: Andy Isaacson @ 2018-09-17 0:20 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List On Sun, Sep 16, 2018 at 12:22:43PM -0700, Linus Torvalds wrote: >This is where the "look yourself in the mirror" moment comes in. > >So here we are, me finally on the one hand realizing that it wasn't >actually funny or a good sign that I was hoping to just skip the >yearly kernel summit entirely, and on the other hand realizing that I >really had been ignoring some fairly deep-seated feelings in the >community. > >It's one thing when you can ignore these issues. Usually it’s just >something I didn't want to deal with. > >This is my reality. I am not an emotionally empathetic kind of person >and that probably doesn't come as a big surprise to anybody. Least of >all me. The fact that I then misread people and don't realize (for >years) how badly I've judged a situation and contributed to an >unprofessional environment is not good. > >This week people in our community confronted me about my lifetime of >not understanding emotions. My flippant attacks in emails have been >both unprofessional and uncalled for. Especially at times when I made >it personal. In my quest for a better patch, this made sense to me. >I know now this was not OK and I am truly sorry. > >The above is basically a long-winded way to get to the somewhat >painful personal admission that hey, I need to change some of my >behavior, and I want to apologize to the people that my personal >behavior hurt and possibly drove away from kernel development >entirely. > >I am going to take time off and get some assistance on how to >understand people’s emotions and respond appropriately. Thank you for writing this, Linus. I have personal experience how difficult it is to be honest, especially publicly, about difficult topics and admitting one's own mistakes. You deserve huge kudos for the journey you've already taken to write the above, and I look forward to the improvements in the lkml culture that are certain to come as a result. The culture of lkml that came about in large part due to your behavior that you alluded to above was a culture that I found amenable, and absorbed, and replicated in other communities and relationships for many years. It took a lot of soul searching and growth to realize for myself that it wasn't healthy, fair, equitable, or amenable to folks from other backgrounds, and to change my own behavior. A big part of that realization and process was that I stepped away from the kernel community completely. I'm still working on getting healthier around this stuff, and that will be a lifelong process I'm sure. If I can help in any way (for example, I have some suggested reading, I can point to therapists and counselors who helped me, and I'm happy to have in depth one on one or small group conversations about these topics), please feel free to reach out. (That goes for others on lkml as well, but I will be fairly guarded about engaging with folks who I don't know or who I don't have confidence are engaging in good faith). -andy ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: […] an apology, and a maintainership note 2018-09-17 7:57 ` […] " Martin Steigerwald @ 2018-09-17 8:53 ` Martin Steigerwald 2018-09-30 12:09 ` Re: Linux 4.19-rc4 released, " lkcl 0 siblings, 1 reply; 24+ messages in thread From: Martin Steigerwald @ 2018-09-17 8:53 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List Martin Steigerwald - 17.09.18, 09:57: > Dear Linus. > > Linus Torvalds - 16.09.18, 21:22: > > This is my reality. I am not an emotionally empathetic kind of > > person and that probably doesn't come as a big surprise to anybody. > > Least of all me. The fact that I then misread people and don't > > realize (for years) how badly I've judged a situation and > > contributed to an unprofessional environment is not good. > > > > This week people in our community confronted me about my lifetime of > > not understanding emotions. My flippant attacks in emails have been > > both unprofessional and uncalled for. Especially at times when I > > made it personal. In my quest for a better patch, this made sense > > to me. I know now this was not OK and I am truly sorry. > > > > The above is basically a long-winded way to get to the somewhat > > painful personal admission that hey, I need to change some of my > > behavior, and I want to apologize to the people that my personal > > behavior hurt and possibly drove away from kernel development > > entirely. > > I applaud you for the courage to go the bold step you have gone with > this mail. I can imagine coming up with this mail has been challenging > for you. > > Your step provides a big chance for a shift to happen towards a more > welcoming and friendly Linux kernel community. From what I saw here as > mostly someone who tests rc kernels and as mostly a by-stander of > kernel development you may not be the only one here having challenges > to deal with emotions. That written: Quite some of the rude mails that contained swearwords I read from you have been about code, not persons. I think this is an important distinction. I do not have much of an issue with swearing at code :), especially when it is in some humorous way. Code quality indeed is important. As are human interactions. -- Martin ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note 2018-09-17 21:09 ` Michael Woods @ 2018-09-18 1:30 ` Pavel Snajdr 2018-09-21 22:13 ` Michael Woods ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Pavel Snajdr @ 2018-09-18 1:30 UTC (permalink / raw) To: michaeljpwoods; +Cc: linux-kernel On 2018-09-17 23:09, Michael Woods wrote: > > The Code of Conflict was perfectly fine. Whomever convinced you to add > the Code of Conduct was convincing you to give control over to a > social justice initiative that has no interest in the kernel's core > function or reason for existence. > Hi Michael, and how about if we viewed the new Code of Conduct as about the same thing as BitKeeper was for the development process? It was not perfect, but wass *something* for a start. And I believe that Linus will probably come back with a Git of CoC, or something in that fasion. I've been always looking up to the guys leading major community projects and how they go about things - and I think, that most of the bad fall-out in them is caused by insanely high expectations - firstly from the leader themselves, and secondly from others as well. /snajpa P.S.: this is my first "contribution" to LKML, I hope to start sending up some of my very prototype work soon for discussion, regarding the Cgroup subsystem ID allocation & limits - and subsequently, start a discussion about getting Linux to do better OS-level containers (ie. those, which have a "look&feel of a real VM" from the admin's perspective). We started our organization (vpsFree.org) on top of OpenVZ patch set and are now working to get vanilla up to the task of replacing the venerable 2.6.32-based OpenVZ 6 Linux-like thing. The new Code of Conduct is a guarantee for us, that we won't be laughed out of the room and that our members won't be demotivated to contribute upstream - if we can all agree to be nice on each other; yet we still need you guys to tell us, when we're trying stupid things or going about things the wrong way, in some way that we will notice & can learn from. If I understand the context correctly, the previous "regime" could be the culprit, at least to some extent, why still don't have the VM look&feel-having containers with vanilla. So I'm just really trying to say, that I'm really excited about the signal this change has sent. ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note 2018-09-18 1:30 ` Pavel Snajdr @ 2018-09-21 22:13 ` Michael Woods 2018-10-04 14:57 ` Eric W. Biederman 2018-10-08 13:54 ` Enrico Weigelt, metux IT consult 2 siblings, 0 replies; 24+ messages in thread From: Michael Woods @ 2018-09-21 22:13 UTC (permalink / raw) To: Pavel Snajdr; +Cc: linux-kernel Hi Pavel, > and how about if we viewed the new Code of Conduct as about the same > thing as BitKeeper was for the development process? You should view the Code of Conduct for what it is, as I referenced previously with real world examples, the evidence shows that it is just a ploy to take control away from the competent and give it to the incompetent. An example of the hypocrisy Linus is in for: a) From Coraline Ada Ehmke's Code of Conduct: > Our Standards > > Examples of behavior that contributes to creating a positive environment > include: > > * Using welcoming and inclusive language and > Examples of unacceptable behavior by participants include: > > * Trolling, insulting/derogatory comments, and personal or political > attacks > * Public or private harassment > * Other conduct which could reasonably be considered inappropriate in a > professional setting b) https://twitter.com/CoralineAda/status/1042249983590838272 > Coraline Ada Ehmke, @CoralineAda > 40,000 open source projects, including Linux, Rails, Golang, and > everything OSS produced by Google, Microsoft, and Apple have adopted > my code of conduct. > > You can make me have a bad day, but it doesn’t change the fact that we > have won and you have lost. > It was not perfect, but wass *something* for a start. A Code of Conduct is not required, to the contrary, all successful software projects, if they wish to remain so, should never adopt one. I previously referenced preferable alternatives. > I've been always looking up to the guys leading major community > projects and how they go about things - and I think, that most of the > bad fall-out in them is caused by insanely high expectations - firstly > from the leader themselves, and secondly from others as well. Linus has excelled up to this point, the Code of Conduct will stifle his ability to maintain the kernel. > The new Code of Conduct is a guarantee for us, that we won't be > laughed out of the room and that our members won't be demotivated to > contribute upstream - if we can all agree to be nice on each other; > yet we still need you guys to tell us, when we're trying stupid things > or going about things the wrong way, in some way that we will notice & > can learn from. The one thing you do not understand, which is key to understanding why complex projects are successful, most people are not intelligent enough to contribute. Their contributions if accepted, would create chaos, and if not simply rejected, would create long backlogs due to the amount of effort required to explain why their code is not of the standard required. > If I understand the context correctly, the previous "regime" could be > the culprit, at least to some extent, why still don't have the VM > look&feel-having containers with vanilla. So I'm just really trying to > say, that I'm really excited about the signal this change has sent. This is not a believable position, that you were waiting for a Code of Conduct before contributing successfully to the Linux Kernel. Regards, Michael ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Re: Linux 4.19-rc4 released, an apology, and a maintainership note 2018-09-17 8:53 ` Martin Steigerwald @ 2018-09-30 12:09 ` lkcl 2018-09-30 14:07 ` Martin Steigerwald 0 siblings, 1 reply; 24+ messages in thread From: lkcl @ 2018-09-30 12:09 UTC (permalink / raw) To: martin; +Cc: linux-kernel, torvalds > That written: Quite some of the rude mails that contained swearwords I > read from you have been about code, not persons. I think this is an > important distinction. I do not have much of an issue with swearing at > code :), especially when it is in some humorous way. absolutely, and this is one thing that a lot of people are, sadly, trained pretty much from birth to be incapable of understanding: namely the difference between criticism of the PERSON and criticism of the ACTION. (1) "YOU are bad! GO STAND IN THE NAUGHTY CORNER!" (2) "That was a BAD thing to do!" (3) "That hurt my feelings that you did that" the first is the way that poorly-trained parents and kindergarten teachers talk to children. the second is... only marginally better, but it's a start the third is how UNICEF trains teachers to treat children as human beings. > Code quality indeed is important. > As are human interactions. absolutely. it's not about the code, it's always, *always* about people. we just happen to be writing code, but ultimately we are doing so in the service of other PEOPLE. l. ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note 2018-09-30 12:09 ` Re: Linux 4.19-rc4 released, " lkcl @ 2018-09-30 14:07 ` Martin Steigerwald 2018-09-30 16:27 ` Luke Kenneth Casson Leighton 0 siblings, 1 reply; 24+ messages in thread From: Martin Steigerwald @ 2018-09-30 14:07 UTC (permalink / raw) To: lkcl; +Cc: linux-kernel, torvalds lkcl@lkcl.net - 30.09.18, 14:09: > > That written: Quite some of the rude mails that contained swearwords > > I read from you have been about code, not persons. I think this is > > an important distinction. I do not have much of an issue with > > swearing at code :), especially when it is in some humorous way. > > absolutely, and this is one thing that a lot of people are, sadly, > trained pretty much from birth to be incapable of understanding: > namely the difference between criticism of the PERSON and criticism > of the ACTION. > > (1) "YOU are bad! GO STAND IN THE NAUGHTY CORNER!" > (2) "That was a BAD thing to do!" > (3) "That hurt my feelings that you did that" > > the first is the way that poorly-trained parents and kindergarten > teachers talk to children. > > the second is... only marginally better, but it's a start > > the third is how UNICEF trains teachers to treat children as human > beings. During releasing a lot of limiting "stuff" I found that probably nothing written or said can hurt my feelings unless I let it do so or even… unless I choose (!) to feel hurt about it. So at times I am clear about this, I´d say: "I have chosen to feel hurt about what you did." However in this human experience a lot of people, including myself, still hold on to a lot of limiting "stuff" which invites feeling hurt. We, as humankind, have a history of hurting each other. During this releasing work I also learned about two key ingredients of successful relationships: Harmlessness and mutuality. I opted out of the hurting cycle as best I can. And so I choose to write in a way that moves around what from my own experience of feeling hurt I know could hurt others. I choose to write in a harmless way so to say. While still aiming to bring my point across. A very important ingredient for this is to write from my own experience. Of course others can feel hurt about something I would not feel hurt about and I may not be aware that the other might feel hurt about. That is why in such a case it is important to give and receive feedback. Still when writing from my own experience without saying that anything is wrong with the other, it appears to be unlikely to trigger hurt. That is at least my experience so far. Thanks, -- Martin ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note 2018-09-30 14:07 ` Martin Steigerwald @ 2018-09-30 16:27 ` Luke Kenneth Casson Leighton 0 siblings, 0 replies; 24+ messages in thread From: Luke Kenneth Casson Leighton @ 2018-09-30 16:27 UTC (permalink / raw) To: Martin Steigerwald; +Cc: Linux Kernel Mailing List, Linus Torvalds On Sun, Sep 30, 2018 at 3:07 PM, Martin Steigerwald <martin@lichtvoll.de> wrote: > lkcl@lkcl.net - 30.09.18, 14:09: >> the third is how UNICEF trains teachers to treat children as human >> beings. > > During releasing a lot of limiting "stuff" I found that probably nothing > written or said can hurt my feelings unless I let it do so or even… > unless I choose (!) to feel hurt about it. So at times I am clear about > this, I´d say: "I have chosen to feel hurt about what you did." it's interesting to me to note that you use the word "releasing". that's a keyword that i recognise from energy work, which, surprisingly is increasingly being recognised and used by individuals and businesses all over the world. it seems that people are beginning to recognise it's actually effective and no longer associated with cloud-cuckoo-land "detached-from-reality" new age hippies. i was going to [privately] recommend someone who specifically works with businesses and organisations to linus: i haven't heard from him yet. > However in this human experience a lot of people, including myself, > still hold on to a lot of limiting "stuff" which invites feeling hurt. > We, as humankind, have a history of hurting each other. this is why i recommended http://pndc.com in my earlier post. one of the documents there points out that due to our still-remaining "survival" instincts from millenia of evolution, words *literally* can have the same effect on us as if we were actually physically and i MEAN literally physically being attacked... [*IF WE CHOOSE* to be]. where people have not yet learned the difference between "that was a bad thing to do" and "YOU are bad" (and interpret those as being exactly the same thing), we have a compound effect. one person says "that's a really dumb piece of code", the person hearing it interprets it as "you're a fucking idiot", and has a LITERAL physical response to the words [that you didn't actually say] as if you'd just punched them in the mouth. > During this releasing work I also learned about two key ingredients of > successful relationships: Harmlessness and mutuality. I opted out of the > hurting cycle as best I can. And so I choose to write in a way that > moves around what from my own experience of feeling hurt I know could > hurt others. I choose to write in a harmless way so to say. While still > aiming to bring my point across. A very important ingredient for this is > to write from my own experience. yes, absolutely. that's pretty much word-for-word exactly the advice given on the _other_ resource i recommended to linus, http://www.crnhq.org/. let me find it.... ok, "appropriate assertiveness": http://www.crnhq.org/CR-Kit.aspx?rw=c#assertiveness quote: " The essence of Appropriate Assertiveness is being able to state your case without arousing the defences of the other person. The secret of success lies in saying how it is for you rather than what they should or shouldn't do. "The way I see it...", attached to your assertive statement, helps. A skilled "I" statement goes even further." and it goes on from there. > Of course others can feel hurt about something I would not feel hurt > about and I may not be aware that the other might feel hurt about. That > is why in such a case it is important to give and receive feedback. > Still when writing from my own experience without saying that anything > is wrong with the other, it appears to be unlikely to trigger hurt. That > is at least my experience so far. exactly. i believe you may be interested to know of the next phases in that: the crnhq's "appropriate assertiveness" advice has a really good template for keeping things to "I", and at the same time successfully getting the point across. i won't quote all of it to you. i believe crhnq is written by a guy who has stopped warring tribes from centuries of killing each other (and i don't mean metaphorically), so it's clearly effective. caveat: my only concern about these kinds of ways of thinking is, sometimes you do actually genuinely need to give people a short, sharp shock: that's part of NLP. *after* the shock, you can be "nice" to them: where previously they were pathologically unable to listen, a shock gets them out of the psychosis that they were in. it's also a recognised medical treatment for people who are hysterical in disaster / emergency scenarios to shock them out of their screaming fit. note: not recommended without proper training!! l. ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note 2018-09-18 1:30 ` Pavel Snajdr 2018-09-21 22:13 ` Michael Woods @ 2018-10-04 14:57 ` Eric W. Biederman 2018-10-08 15:29 ` Enrico Weigelt, metux IT consult 2018-10-08 13:54 ` Enrico Weigelt, metux IT consult 2 siblings, 1 reply; 24+ messages in thread From: Eric W. Biederman @ 2018-10-04 14:57 UTC (permalink / raw) To: Pavel Snajdr; +Cc: michaeljpwoods, linux-kernel Pavel Snajdr <snajpa@snajpa.net> writes: > > We started our organization (vpsFree.org) on top of OpenVZ patch set and are now > working to get vanilla up to the task of replacing the venerable 2.6.32-based > OpenVZ 6 Linux-like thing. The new Code of Conduct is a guarantee for us, that > we won't be laughed out of the room and that our members won't be demotivated > to contribute upstream - if we can all agree to be nice on each other; yet we > still need you guys to tell us, when we're trying stupid things or going about > things the wrong way, in some way that we will notice & can learn from. > If I understand the context correctly, the previous "regime" could be the > culprit, at least to some extent, why still don't have the VM look&feel-having > containers with vanilla. At an implementation level namespaces and cgroups are hard. Coming up with a good solid design that is very maintainable and handles all of the corner cases is difficult. Very few people choose to do the work of digging into the details and figuring out what is really needed. This is not an area where you can hand hold someone. It really takes people who are able to work out from first principles what the code will need to do. Very often people will propose patches that do solve their specific case but only do 10% or maybe 20% of what is needed for a general kernel level solution. For something that just works and does not cause maintenance problems in the long run. Someone has to deep dive and understand all of the problems and sort it out. That takes a person that is willing and able to stand up with all of the rest of the kernel developers as an equal. It requires listening to other opinions to see where you need to change and where things are wrong but it also requires being able to figure things out for yourself and to come up with solid technical contributions. I hope I have been something reasonable to work with on this front, if not please let me know. I know many other maintainers get hit with such a stream of bad container ideas that they tend to stop listening. As their priorities are elsewhere I don't blame them. Also don't forget that most of the time to do a good implemenation that it requires rewriting an entire subsystem to make it container friendly. Think of the effort that requires, especially when you are not allowed to cause regressions in the subystem while rewriting it. Further the only power a maintainer has is to accept patches, to listen to people, and to express opinions that are worth listening to. In the midst of doing all of those things a maintainers time is limited. You said a change in attitude gives you optimism that you can make work with the upstream kernel. I am glad you have optimism as overall the kernel is a welcoming place. At the same time there can't be guarantees that people won't be demontivated. If you care about the remaining kernel problems for implementing containers, you need to realize those that are difficult problems that don't easily admit to solutions. That is why the problems still remain. To get a small flavor just look at how much work I had to go through to sort out siginfo in the kernel which is just one very small piece of the larger puzzle. So please realize that sometimes actually realizing the scope of the technical difficulties might be demotivating in and of itself. Similarly because maintainers have a limited amount of time there are no guarantees how much we can help others. We can try but people have to meet maintainers at least half way in figuring out how things work themselves, and sometimes there is just not enough time to say anything. As the old saying goes: "You can lead a horse to water but you can't make him drink". So there are no guarantees that people won't be demotivated or that they will learn what is necessary. All that we can do is aim to keep conversations polite and focused on the technical details of the project. Which should keep things from getting unpleasant at the level of humans interacting with humans. I don't think that will give you greater guarantees beyond that, and it feels like you are reading greater guarantees into recent events. I would like to see what you see as missing from the mainline kernel. But that is a topic for the containers list, and possibly for the containers track at Linux Plumbers conference in Vancouver. Eric ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note 2018-09-18 1:30 ` Pavel Snajdr 2018-09-21 22:13 ` Michael Woods 2018-10-04 14:57 ` Eric W. Biederman @ 2018-10-08 13:54 ` Enrico Weigelt, metux IT consult 2 siblings, 0 replies; 24+ messages in thread From: Enrico Weigelt, metux IT consult @ 2018-10-08 13:54 UTC (permalink / raw) To: Pavel Snajdr, michaeljpwoods; +Cc: linux-kernel On 18.09.2018 03:30, Pavel Snajdr wrote: Hi folks, I usually try to stay out of political issues in software projects (there're already too much real political problems, where people need to stand up and push away actual oppressors), but now I have the bad feeling that political (or more precisely: social engineering) techniques are abused against the Linux kernel project. > and how about if we viewed the new Code of Conduct as about the same> thing as BitKeeper was for the development process? Bitkeeper was used as an intermediate workaround for conceptional deficiencies in CVS (and all other tools based on the same principles). But I really don't see any conceptional deficiencies in the way the Linux kernel community worked in the last decades. Actually, it worked very, very well. It created the best general purpose OS kernel in known history, that scales from small embedded to big clusters. And this has *VERY MUCH* to do with how the community worked for the last decades. IMHO, it's even the primary reason. Not having to care about personal behaviours, corporate hierarchies, marketing, whatsnot, only care about technical excellence. Nothing more, nothing less. > It was not perfect, but wass *something* for a start. A start for what exactly ? Just for the sake of doing *something* ? Well, that sounds like the typical corporate manager's / politician's behaviour pattern: There seems to be a problem, we need to do something fast - doing nothing is worse than not doing anything quick enough. Yeah, that's exactly what I'm regularily observing with my clients (the bigger the corporation, the worse). And that's exactly why so many of their projects fail so miserably, and products are such a crap. I really hate the idea of the Linux community falling into the same trap. (many of the GUI projects already did, and their code is crap) The best thing, IMHO, is to totally ignore any kind 'social rules' and focus on the actual technical goals. And don't take anything here personally. *If* there really happen some ugly personal attacks, we can talk about that on a case by case basis. > I've been always looking up to the guys leading major community projects> and how they go about things - and I think, that most of the bad> fall-out in them is caused by insanely high expectations - firstly from> the leader themselves, and secondly from others as well. Can you give some example of such bad fall-out ? > P.S.: this is my first "contribution" to LKML, I hope to start sending> up some of my very prototype work soon for discussion, regarding the> Cgroup subsystem ID allocation & limits - and subsequently, start a> discussion about getting Linux to do better OS-level containers (ie.> those, which have a "look&feel of a real VM" from the admin's perspective). Please add me to CC. I'm working on similar areas (if my time budget allows ;-)). Even better: create a separate maillist for that, if there's not already some fitting one. LKML's a pretty crowded already. > We started our organization (vpsFree.org) on top of OpenVZ patch set and> are now working to get vanilla up to the task of replacing the venerable> 2.6.32-based OpenVZ 6 Linux-like thing. What exactly are you yet missing in current mainline ? Are these things that really need to be done in the kernel or could it be done in userland ? My personal area of interest in the container context isn't the usual 'put a whole system in a box'-thing, but instead using namespace isolation an general software architectual feature, similar to the Plan9 world - eg. allow unprivileged processes to manipulate their own fs namespace at will, use synthetic filesystems as generic IPC, split huge applications into small and resusable programs, etc. > The new Code of Conduct is a guarantee for us, that we won't be laughed out > of the room and that our members won't be demotivated to contribute upstream Seriously ? You really need some kind of 'social law' that protects you from the risk of being laughed out ? No offense, but if that's really the case, then you've got a much bigger, more serious problem, which also persuades you in your daily life: deep lack of self confidence. I feel very sorry for that, and I'm offering my help. For anybody who feels that way. Yes, I had exactly that problem for my whole childhood and youth, until I've learned a vital lesson: It just *DOES NOT* matter whether some people laugh about you or your work - as long as you're sure that you your work is the right thing for *YOU*. Simply ignore the trolls. (BTW, the really good point on FOSS is: you can fork anytime and do whatever changes you feel right for you - no matter what anybody out there thinks about them). So, don't let such things come into your way. Just do whatever you feel the right thing to do and then let's talk about that. I have no idea whether your patches have a chance to mainline anytime soon. But that shouldn't even matter. Solving a specific problem and fitting in something into the big generic world are two entirely different things. Many great things (eg. various container subsystems, realtime, android stuff, ...) went a long way towards mainline, some still have a long way to go. That's just because it's these topics are far from being trivial. And that shouldn't stop anybody. > If I understand the context correctly, the previous "regime" could be > the culprit, at least to some extent, why still don't have the VM > look&feel-having containers with vanilla. Why exactly do you think so ? What exactly are you missing here ? Where's the connection to social rules ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287 ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note 2018-10-04 14:57 ` Eric W. Biederman @ 2018-10-08 15:29 ` Enrico Weigelt, metux IT consult 0 siblings, 0 replies; 24+ messages in thread From: Enrico Weigelt, metux IT consult @ 2018-10-08 15:29 UTC (permalink / raw) To: Eric W. Biederman, Pavel Snajdr; +Cc: michaeljpwoods, linux-kernel On 04.10.2018 16:57, Eric W. Biederman wrote: > Very often people will propose patches that do solve their specific case > but only do 10% or maybe 20% of what is needed for a general kernel > level solution. For something that just works and does not cause > maintenance problems in the long run. One of the cases is the hard realtime stuff. A perfect implementation for hard-RT environments can easily turn out as total crap for generic server workloads. So, these things really take time make both worlds fit together. For those cases, it's often better to maintain it as a separate tree/patchset and step by step try to bring those pieces to mainline, that fit in there. > I know many other maintainers get hit with such a stream of bad > container ideas that they tend to stop listening. As their priorities > are elsewhere I don't blame them. Let's put it that way: these ideas probaly aren't necessarily bad as such, but just don't fit into mainline (yet). OVZ is such a case: it's s good thing for a range of usecases, and pretty successful there. But it conflicts lots of other places that the mainline has to support. Therefore it has to stay a separate tree, until we've found a better solution, somewhere in the future. > Similarly because maintainers have a limited amount of time there are no > guarantees how much we can help others. We can try but people have to > meet maintainers at least half way in figuring out how things work > themselves, and sometimes there is just not enough time to say anything. Yes. I've been demotivated by this problem myself. But I know, I can't expect anybody else do to my homework for me. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287 ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note 2018-09-16 19:22 Linux 4.19-rc4 released, an apology, and a maintainership note Linus Torvalds ` (8 preceding siblings ...) 2018-09-17 21:09 ` Michael Woods @ 2018-10-08 16:36 ` Enrico Weigelt, metux IT consult 9 siblings, 0 replies; 24+ messages in thread From: Enrico Weigelt, metux IT consult @ 2018-10-08 16:36 UTC (permalink / raw) To: Linus Torvalds, Linux Kernel Mailing List On 16.09.2018 21:22, Linus Torvalds wrote: Hi, <snip> > One was simply my own reaction to having screwed up my scheduling of > the maintainership summit: yes, I was somewhat embarrassed about > having screwed up my calendar, but honestly, I was mostly hopeful that > I wouldn't have to go to the kernel summit that I have gone to every > year for just about the last two decades. IMHO, if you - for whatever reason - want to skip a conference, it's your right to do so. You've done so much for us, you deserve a break. > This is my reality. I am not an emotionally empathetic kind of person > and that probably doesn't come as a big surprise to anybody. Least of > all me. The fact that I then misread people and don't realize (for > years) how badly I've judged a situation and contributed to an > unprofessional environment is not good. I, personally, never felt the Linux kernel community was anything like an unprofessional environment in any way. Quite the opposite. Certainly, there's room for improvement here and there, but IMHO, the general situation is the best of all projects I've been involved in. Don't be so hard on yourself. > This week people in our community confronted me about my lifetime of > not understanding emotions. My flippant attacks in emails have been > both unprofessional and uncalled for. Especially at times when I made > it personal. In my quest for a better patch, this made sense to me. > I know now this was not OK and I am truly sorry. Maybe I've missed these mails you're referring to, but I didn't see anything which IMHO wasn't justified. Even if you'd call a patch of mine "the greatest bullshit i've ever seen", I wouldn't consider this a personal attack for a ns. Because I know I would have come from a completely different perspective than mine. > The above is basically a long-winded way to get to the somewhat > painful personal admission that hey, I need to change some of my > behavior, and I want to apologize to the people that my personal > behavior hurt and possibly drove away from kernel development > entirely. I don't know anybody of these people personally, so I won't judge on that. I've just seen some blog posts, which looked pretty subjective to me and didn't tell what exactly happened. My theory is that people took things personal, which haven't been personal at all. But that seems to be a general problem, which is far out of scope of any professional software project. > This is not some kind of "I'm burnt out, I need to just go away" > break. I'm not feeling like I don't want to continue maintaining > Linux. Quite the reverse. I very much *do* want to continue to do > this project that I've been working on for almost three decades. :) > And yes, some of it might be "just" tooling. Maybe I can get an email > filter in place so at when I send email with curse-words, they just > won't go out. Because hey, I'm a big believer in tools, and at least > _some_ problems going forward might be improved with simple > automation. In that case, I doubt it's a matter of tooling. It would require a kind of artificial intelligence, that hasn't been invented yet. NP complete problem. If you really feel, your reactions on certain things, your way of communication was a problem, then I'd raise the question why such feelings, that trigger these reactions, come into your mind in the first place. I've been through something similar. I easily got angry about by bad code and people not understanding things I considered self-evident. And in my case, it actually escalated onto the personal level. My approach was self-monitoring of my feelings and behaviour. Whenever I felt my blood presure reasing, I took a cigarette break and thought about why I'm thinking that way now. Usually, I came to the conclusion that these folks who did some crap again, just don't know better, they never seen what I've seen. And it's my job to train them. This way of thinking helped me a lot, maybe it could help you and all there other, too. > I know when I really look “myself in the mirror” it will be clear it's > not the only change that has to happen, but hey... You can send me > suggestions in email. Unfortunately, I have no idea, what exactly you've seen in the mirror. I can only judge on what I've seen here in the last decades. And I like you exactly that way. Especially the rude part, eg. when it's about corporations like NVidia, or people who try to refit the Kernel for their broken userland stuff. If I may propose a patches to your /dev/brain, the only issue would be 100% strict GPL enforcement ;-) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287 ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note 2018-09-17 2:15 Luke Kenneth Casson Leighton 2018-09-18 2:10 ` Luke Kenneth Casson Leighton @ 2018-09-30 11:47 ` Luke Kenneth Casson Leighton 1 sibling, 0 replies; 24+ messages in thread From: Luke Kenneth Casson Leighton @ 2018-09-30 11:47 UTC (permalink / raw) To: Linus Torvalds, Linux Kernel Mailing List https://linux.slashdot.org/story/18/09/27/1529236/linus-torvalds-on-linuxs-code-of-conduct#comments linus: ah... um... okay so this is beginning to remind me of dr who films, the comedy film "the world's end", and various other b-movie horror shows where people were taken over through mind-control or replaced. so i apologise, i'm going to stop pussy-footing around and ask HAVE YOU FUCKING LOST IT, GET YOUR HEAD OUT YOUR ARSE, STOP FEELING SORRY FOR YOURSELF AND GET BACK TO BEING AN ENGINEER, YOU ARE ON A CHEARRRRGEUUH YOU SORRY LITTLE PROGRAMMERRRRR *cough*. enough NLP-esque shock tactics with a bit of comedy thrown in to take the sting out of it... allow me to return to rational insights. (1) you apologised for your behaviour, and it's fantastic that you recognised that there was a problem and asked for help. however, you *may* be feeling a little guilty, and it's clearly knocked your confidence, and that unfortunately has allowed political correctness to "creep in" where we know it never, ever belongs: in engineering. the next thing you know, the fucking guilt-ridden morons who want the words "master" and "slave" erased from the history books will be telling you that we have to change SPI's "MOSI" and "MISO" to... god... i dunno... "ROWI and RIWO" - "requestor" and "worker" or something incredibly stupid: Requestor: "i'm awfully sorry, if you wouldn't mind, if it's not too much trouble mr worker, when you have the time and you're not on your union-mandated break, could you deal with this bit-change for me?" (2) more and more people are raising the fact that the change was made without consultation. this *is* going to bite everyone. i strongly, strongly suggest reverting it: i made the point very clear that it wasn't the actual CoC that was the problem, it was that you, yourself, were not really obeying it (so nobody else could, either). (3) let's look at what toxic documents named "codes of conduct" look like from an engineering perspective: #define BEHAVIOUR_GOOD() ((~BEHAVIOUR_BAD) == 0) #define BEHAVIOUR_BAD BEHAVIOUR_SEXIST | BEHAVIOUR_RACIST | BEHAVIOUR_NAZI | BEHAVIOUR_UNPLEASANT | BEHAVIOUR_RELIGIOUS_EXTREMIST .... #define BEHAVIOUR_RELIGIOUS_EXTREMIST \ BEHAVIOUR_ANTI_CHRISTIAN \ BEHAVIOUR_ANTI_MUSLIM \ ... .... .... #define BEHAVIOUR_ANTI_MUSLIM 0x1 #define BEHAVIOUR_ANTI_CHRISTIAN 0x2 ... ... ... // oops fuck we're gonna run out of bits extremely quickly.... do you see where that's going? do you get the point already? if an engineer proposed the above patch to create the toxic CoC document that insidiously crept in recently, you and pretty much everyone would think that the submitter had a fucking screw loose and needed psychiatric help. these toxic documents do not have to spell it out, but they *imply* that there are (deep breath...) spics, wocs, niggers, honky white bastards, chinks kooks and their mothers too all trying to ATTACK the project, and we'd better make sure that they're all excluded, otherwise we're all in trouble, eh? i apologise for using these words: if you are a decent human being you should by now feeling physically sick to your stomach at having read that paragraph, that those words were even used... yet they're not actually *in* that toxic document, but they don't have to be: people are still thinking them. like the "don't think of a pink elephant" our subconscious mind cannot help by strip out the "don't". bottom line: the *entire linux kernel project* has now been *completely poisoned* by that document. put another way: an engineer would go, "wtf??" and would say "we don't need to fill every single bit in the bitfield and then invert it for god's sake! just say "good behaviour is expected" and be done with it!!" so why not say, instead of that absolute god-awful list, "everyone is welcome; everyone belongs". you see the difference? you see how simple and empowering that is? it's INVITING people to participate, and it's pretty obvious that if someone feels *UN*welcome, the rules have been broken and they can raise it as an issue. rather than absolutely terrifying and sickening absolutely everybody. the analogy is the story of mother theresa being invited to an "anti-war" rally. she declined... and said, "if ever you hold a PEACE rally, i'd be delighted to attend". so come on, linus: wake up, man. just because this is outside of your area of expertise does not mean that you have to let go of the reins. *get a grip*. use your engineering expertise, apply it to the problem, work with *EVERYONE* and work out an *ACCEPTABLE* solution. warmest, l. ^ permalink raw reply [flat|nested] 24+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note @ 2018-09-17 2:15 Luke Kenneth Casson Leighton 2018-09-18 2:10 ` Luke Kenneth Casson Leighton 2018-09-30 11:47 ` Luke Kenneth Casson Leighton 0 siblings, 2 replies; 24+ messages in thread From: Luke Kenneth Casson Leighton @ 2018-09-17 2:15 UTC (permalink / raw) To: Linus Torvalds, Linux Kernel Mailing List hi linus, just saw the note on slashdot. i just wanted to say how amazed, relieved and delighted i was to see what you wrote. that you recognised that you needed to reflect, *sought feedback*, and, most importantly, were willing and able to discuss that and ask publicly. as the longest-serving contributor with the highest expertise, on *the* world's largest software project by a long, long margin, your words have a staggeringly-high "weight", so it is absolutely inspiring (and a huge relief). you therefore deserve a thoughtful answer. however, i thought it best to also provide some "immediate" feedback, as well. as someone who has had... *deep breath*... an extremely difficult time in the software libre world due to holding strict ethical values with high integrity, i have had to do one hell of a lot of research into resources to help with communication and dealing with conflict. whilst they are not actually the real underlying concept, they're guides and tools that are at least intellectually understandable, if that makes any sense: * the bill of ethics - https://www.titanians.org/the-bill-of-ethics/ * the titanian's "code of honour" - https://www.titanians.org/titanian-code-of-honor/ * the "conflict resolution network" - http://www.crnhq.org/ (see "12 skills summary") * powerful non-defensive communication - http://pndc.com/ * "Invisible Dynamics" - https://www.amazon.co.uk/dp/3896704915 (specifically the page outlining the 6 systemic laws of organisations: page 23 i *think*. my copy unfortunately is in storage). * the "MASH" actor who is teaching scientists to communicate: https://motherboard.vice.com/en_us/article/mgbwkn/how-a-former-mash-actor-is-teaching-scientists-to-be-extroverts last on the list (and i prefer not to provide a link as it may need explanation, and the website is too specific / slightly mis-directing) if you're specifically considering some sort of "coach" to work with, do contact me off-list and i can recommend someone who has helped me, who also has experience helping businesses and organisations, not just individuals. it's very late here, so i will put some thought into a more comprehensive reply over the next couple of days: the main thing that i wanted to get across straight away was that i am responding precisely because your message resonates with, and is basically indicative of, ethical behaviour. as in, just the very act of asking for constructive feedback is an absolute and fundamental requirement for anyone wishing to call their behaviour "ethical". why? because if you're not asking others for *outside* help in evaluating if you are acting ethically, how the hell can you ever tell if your behaviour is "good" or "bad"?? as in: you absolutely cannot tell if you are "on-target" to reach a goal if you don't have any kind of feedback loop! it's real simple, and yet so many people go through life completely unconscious of, unaware of, and unable to discuss or even think about, this absolutely simple and fundamental requirement! and that alone is really, *really* important. we have way, *way* too many software libre projects increasing in importance that are also operating completely unethically, yet they *genuinely* believe that just because the source is "open", everything must automatically be "fine". i won't give examples: there's just simply too many. so what you've said that you intend to do, here, is not just about you: you've created a key pivotal moment that will show other projects why it's not just about the code: it's about people, and communication. it always has been. *thumbs-up*. l. ^ permalink raw reply [flat|nested] 24+ messages in thread

LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ linux-kernel@vger.kernel.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git