[ 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
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.
> 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
Hi Linus.
I was "around linux-kernel" some 10 years ago and still to this date
sometimes check e.g. lkml.org where I happened upon this; felt it hard
to resist commenting on one specific bit...
Whereas you concentrate on net-positive effect on code quality of an at
times "crass" communication style, I believe there is or used to be an
actually larger net-positive on community: the very fact that you as
project leader feel/felt free to sometimes tell people off is and is I
believe widely taken to be a sign that the Linux project leader still
considers himself part of the community; is anti-hierarchical in that
sense, and as such a large positive for a community a significant
majority of which would not have (had) it any other way.
Now, Linux has of course long outgrown its hacker-beginnings; I would
expect that by now an overwhelming majority of developers is part of
a corporate hierarchy anyway and therefore not themselves free to respond
to you "on equal terms" even if they were personally inclined to do so.
The above may hence be somewhat obsolete in reality -- and I'm also
sure that this is for you more personal than for someone like me reading
it on LKML(.org), but hearing you describe your style up to now as
_wrong_ still feels quite, well, wrong.
At the very least historically it wasn't, and it if is more now it
at the very least still reflects quite positively on honesty and
openness.
Rene.
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
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.
The new kernel rc release is good news as always. The rest of this? not
so much.
"I can’t wait for the mass exodus from Linux now that it’s been
infiltrated by SJWs. Hahahah" -- @CoralineAda on Twitter [1][2]
You really want people like this attempting to sabotage FOSS projects?
I for one am not discontinuing usage of Linux over any political BS,
and I believe it is foolish for anyone to leave any software project
over politics, but that does not mean I welcome political agendas in
software development.
Your old Code of Conflict was perfect and succinct. If someone cannot
use their head to figure out what is right or wrong to say in a mailing
list or a commit message, that person is unfit for contributing to
software in general. This doesn't need to be spelled out for anyone. We
didn't need to explicitly bar discriminatory speech from software
discussion, because software discussion was never the place to have
discrimination against people -- it only allows for discrimination
against shitty code. You, Linus, have never attacked anyone from what I
have seen; you have only attacked poorly-decided actions, which is
perfectly justified. People who really want to contribute to Linux dust
their shoulders off, take your criticism, and figure out how to
re-approach you depending on what they did that was not to your taste.
Anyone who shies away from criticism is IMO unfit to contribute in the
first place. I mean, yes, there are ways to get your criticisms across
in a more "constructive" tone, but this does not call for any code of
conduct. Maybe you do need to take time to figure out how you want to
approach the community, but don't take it that you *have* to do
anything. You don't have to do a thing. People will still use Linux
regardless. People who care about Linux will continue to contribute to
it, because they do not take your words personally (nor should they).
This Code of Conduct trend is nothing but a concern-trolling campaign
that people carry out in order to gain control over projects,
organisations, and communities. Everyone is best off if we do not give
these people the control they desire. Take their demands with a grain
of salt: they suggest a boilerplate Code of Conduct, you decide which
parts from which Linux can benefit, if any.
[1] https://twitter.com/CoralineAda/status/1041441155874009093
[2] http://archive.is/1iGmk
This is just another two cents from a fellow faceless transgender woman
on the Internet, yours truly,
--
wowaname <https://wowana.me/pgp>
Please use detailed subject lines and reply below quoted text
whenever possible.
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.
I once learned that there may be two types of personality, one who dives
deeply into emotions and one who does not. Two types of personality who
often have challenges to understand each other. I believe that people of
those two types of personality can learn from each other.
It is important to move beyond right and wrong or good and bad in this.
Whenever I act, I receive feedback (even the lack of feedback is a
feedback). Do I like this feedback? Or do I like to create a different
result? If I like to create a different result, its important to act
differently, as its unlikely that the same behavior will create a
different result.
Thank you, Linus.
--
Martin
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
On Sun, Sep 16, 2018 at 12:22:43PM -0700, Linus Torvalds wrote:
> [ 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.
>
Build results:
total: 135 pass: 134 fail: 1
Failed builds:
sparc32:allmodconfig
Qemu test results:
total: 315 pass: 315 fail: 0
All problems fixed except for the sparc32 build problems. I'll keep
building sparc32:allmodconfig for the time being, but I may drop it
by the time of the final release.
As for runtime warnings, the only warning left in my test boots is
WARNING: CPU: 0 PID: 1 at mm/slab.c:2666 cache_alloc_refill+0x8a/0x594
for sh4 boots. This has been discussed at
https://lkml.org/lkml/2018/8/3/773
https://www.spinics.net/lists/linux-sh/msg53298.html
https://marc.info/?t=153301426900002&r=1&w=2
but unfortunately the discussion has stalled.
Guenter
On Sun, 2018-09-16 at 12:22 -0700, Linus Torvalds wrote:
> Greg Kroah-Hartman (1):
> Code of Conduct: Let's revamp it.
I believe it would be better if this sort of change
had on-list and public discussion before being applied.
Hi Linus,
> The one change that stands out and merits mention is the code of
> conduct addition...
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.
"Codes of conduct are tools used by the incompetent to wrest control
away from the people who own the project, so they can feed on the corpse
and wear the skin of the project as a fetish play"
Examples of these people trying to introduce codes of conduct, with
commentary on the emotions and motivations driving CoC introduction:
- LLVM: http://voxday.blogspot.com/2018/05/the-costs-of-code-of-conduct.html
- PHP: http://voxday.blogspot.com/2016/01/initial-sjw-attack-defeated.html
- PHP 2: http://voxday.blogspot.com/2016/01/a-second-sjw-attack-on-php.html
- Ruby: http://voxday.blogspot.com/2016/01/more-sjw-attacks-in-tech.html
- Ruby 2:
http://voxday.blogspot.com/2016/01/the-sjw-war-on-ruby-continues.html
- Node.js: http://voxday.blogspot.com/2017/08/how-sjws-react-to-defeat.html
- Awesome-Django:
http://voxday.blogspot.com/2015/10/exposing-true-face-of-sjw.html
- Go: http://voxday.blogspot.com/2015/06/you-cant-run-you-cant-hide.html
Some alternative ideas should you wish to rethink the Code of Conduct:
- Code of Merit: http://voxday.blogspot.com/2016/01/code-of-merit.html
- No Code of Conduct:
http://voxday.blogspot.com/2016/01/no-code-of-conduct.html
> 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.
It has been good, this is easily proven by the quality and success of
the Linux kernel. If you start being "nice" instead of forthright, every
excuse in the mental health cookbook will be used to persuade you that
emotions of the incompetent and their politics, are more important than
improving the kernel.
> 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.
You are not that bad. The incompetent and mentally ill have convinced
you to act against your best interests, and those of the Linux kernel.
> I am going to take time off and get some assistance on how to
> understand people’s emotions and respond appropriately.
Don't try to understand people's emotions, it has not been necessary and
is not necessary. It is a trap, set to weaken your resolve and standards.
> 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.
> 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 wish you the very best, my hope is that you recuperate & take stock,
realise how the snakes tricked you and come back with a vengeance.
Kindest Regards,
Michael
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.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a104f8b5867c682d994ffa7a74093c54469c11f
ahh, guys? ah... i'm going to try *really* hard to follow the advice
that's listed here ok?
http://www.pndc.com/documents/_PDF%20Text-PNDC%20WORKS.pdf it's a
little challenging to do so in email, as it's specifically designed
(page 6) for face-to-face conversations.
following point (1) on page 6, i believe that the question i should
be asking is best phrased as follows:
* what was the intent behind the change to a "code of conduct"?
following point (4) on page 7, a second question i believe should be
phrased as follows:
* whilst the "positive" list of behaviours look good on first glance,
we've witnessed what happened with freebsd when they adopted a "code
of conduct": would a (public) reasonable and rational discussion with
a view to removing the "proscribed" list of negative behaviours be
welcome? [1]
l.
[1] it's a little more complex than that, you get the general idea.
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.
In software projects, there will be no "calling out" of bad behaviour
for the self identifed victims this was written for, whom are invariably
the least useful contributors and most capable of inventing victim
narratives. The CoC will be used by the mentally ill and incapable to
create accusations for attacking competent individuals.
> 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
linus, hi,
i haven't been able to get hold of a copy of "invisible dynamics" yet
however my partner did track down a... "translation" of the six
systemic laws from family to organisational principles (from where
they were originally derived). the book puts the systemic laws in a
clearer way and explains them very well, where i think the attached
was an effort to show the origin.
i have witnessed many times where free softwre projects violate these
systemic laws: those projects fail, pure and simple. sometimes that
failure takes a while: they fail nonetheless.
one particularly interesting aspect of these systemic laws of
organisations is: they really are laws. they're not "principles that
are optional to uphold". i regularly encounter people who say "i
don't believe in this rubbish you are spouting, it can't possibly be
(a) true (b) apply to me" [thus ironically violating the aspect of
"respecting contributors"] yet more than that they do not realise that
these systemic laws take effect and apply *regardless of whether
participants believe in them*.
i think, really, why i was so delighted and relieved at what you wrote
was: you finally acknowledged a long-standing systematic violation of
some of these laws, and promised to fix that. (a) treating people
with dignity (b) treating people with respect: these are at least two
that you recognised and promised to fix.
the new code of conduct (which... well... it's a good idea to read the
top comments here [1] in particular the one "can't be examined in
isolation") and also the original code of conflict, in both there are
unfortunately things still missing that, if left out, will continue to
cause problems.
one main insight that occurred to me over the past few days: the
change from a code of conflict to a code of conduct, it wasn't so much
the lack of wider consultation that bothered me as much as it has
other people, nor the change to a "proscribed list of toxic (and ever
incomplete) behaviours" [2], as i do not believe that that *actually*
was the problem in the first place.
the problem i feel was that because you, as the longest-standing
member and the member with the highest expertise, were not respecting
the code, absolutely nobody else could possibly follow or enforce it,
either. as in: how comfortable do you think the people tasked with
enforcing the code would feel about raising an issue with you, when
they received a complaint about your prior behaviour? and that's why
it was so, so important that you acknowledged this, and invited people
to give you feedback, and *promised to listen*.
the last major insight i wanted to give you is this: don't feel
guilty, and for god's sake don't be tempted to abandon your
responsibilities just because you're "reflecting"! you don't do
software development on your own (because we know that more eyes fix
bugs), and more to the point, if you go off and "fix" your behaviour
(privately), um... how do we know that it's *actually* what's needed
to be "fixed"?
so can i make a suggestion? treat "yourself" as "another bug-ridden
free software project to be fixed"! create a mailing list, create a
group, invite people to participate, with a pledge and a goal "Fix Our
Behaviour And Learn To Be Better Software Libre Developers". it's not
about *you*, Linus, it's about *people* and about *communication*, it
always has been. ... so why are you going away to fix "you", when
actually you need to learn *interaction* with others, and get rapid
cyclic feedback on that, and the best way to do that is, i feel, treat
it as another open project, complete with mailing list, roadmap and
everything! :)
that way, you get some fantastic feedback, you get to learn *and then
teach by example* how to turn the world's largest software project
into a *really good* software project that shows people across the
world how it really should be done.
lastly, if you (or anyone else) is wondering how i can have the...
um... "gall" to make these suggestions, it's very simple: the linux
kernel is installed on hundreds of millions of devices across the
world. if there's a problem with how it's developed, that's
*everyone's* problem, including mine. i take responsibility for
standing up and saying "scuse me, this affects me if it's causing
people pain", and so should you.
/respect, linus.
l.
[1] https://linux.slashdot.org/story/18/09/18/1441230/linux-community-to-adopt-new-code-of-conduct#comments
[2] https://news.ycombinator.com/item?id=9742223 - "if you have to
actually spell out that they shouldn't be hateful, there's a bigger
problem at stake"
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.
> 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.
[email protected] - 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
On Sun, Sep 30, 2018 at 3:07 PM, Martin Steigerwald <[email protected]> wrote:
> [email protected] - 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.
Pavel Snajdr <[email protected]> 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
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
[email protected] -- +49-151-27565287
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
[email protected] -- +49-151-27565287
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
[email protected] -- +49-151-27565287