LKML Archive on lore.kernel.org
 help / 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; 21+ 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] 21+ 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; 21+ 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] 21+ 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; 21+ 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] 21+ 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
  2018-09-16 21:42 ` [...] " Adam Borowski
@ 2018-09-17  0:18 ` " Rene Herman
  2018-09-17  0:20 ` [...] " Andy Isaacson
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 21+ messages in thread
From: Rene Herman @ 2018-09-17  0:18 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel



^ permalink raw reply	[flat|nested] 21+ 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; 21+ 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] 21+ 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
                   ` (2 preceding siblings ...)
  2018-09-17  0:20 ` [...] " Andy Isaacson
@ 2018-09-17  0:23 ` " Rene Herman
  2018-09-17  6:57 ` opal hart
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 21+ messages in thread
From: Rene Herman @ 2018-09-17  0:23 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel

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.

^ permalink raw reply	[flat|nested] 21+ 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
                   ` (3 preceding siblings ...)
  2018-09-17  0:23 ` Linux 4.19-rc4 released, " Rene Herman
@ 2018-09-17  6:57 ` opal hart
  2018-09-17  7:57 ` […] " Martin Steigerwald
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 21+ messages in thread
From: opal hart @ 2018-09-17  6:57 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel

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.

^ permalink raw reply	[flat|nested] 21+ 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
                   ` (4 preceding siblings ...)
  2018-09-17  6:57 ` opal hart
@ 2018-09-17  7:57 ` " Martin Steigerwald
  2018-09-17  8:53   ` Martin Steigerwald
  2018-09-17 12:58 ` Guenter Roeck
                   ` (3 subsequent siblings)
  9 siblings, 1 reply; 21+ messages in thread
From: Martin Steigerwald @ 2018-09-17  7:57 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

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



^ permalink raw reply	[flat|nested] 21+ 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; 21+ 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] 21+ 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
                   ` (5 preceding siblings ...)
  2018-09-17  7:57 ` […] " Martin Steigerwald
@ 2018-09-17 12:58 ` Guenter Roeck
  2018-09-17 17:09 ` Joe Perches
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 21+ messages in thread
From: Guenter Roeck @ 2018-09-17 12:58 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 21+ 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
                   ` (6 preceding siblings ...)
  2018-09-17 12:58 ` Guenter Roeck
@ 2018-09-17 17:09 ` Joe Perches
  2018-09-17 21:09 ` Michael Woods
  2018-10-08 16:36 ` Enrico Weigelt, metux IT consult
  9 siblings, 0 replies; 21+ messages in thread
From: Joe Perches @ 2018-09-17 17:09 UTC (permalink / raw)
  To: Linus Torvalds, Linux Kernel Mailing List; +Cc: Greg KH

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.


^ permalink raw reply	[flat|nested] 21+ 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
                   ` (7 preceding siblings ...)
  2018-09-17 17:09 ` Joe Perches
@ 2018-09-17 21:09 ` Michael Woods
  2018-09-18  1:30   ` Pavel Snajdr
  2018-10-08 16:36 ` Enrico Weigelt, metux IT consult
  9 siblings, 1 reply; 21+ messages in thread
From: Michael Woods @ 2018-09-17 21:09 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 21+ 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; 21+ 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] 21+ 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     ` ebiederm
  2018-10-08 13:54     ` Enrico Weigelt, metux IT consult
  2 siblings, 0 replies; 21+ 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.
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

^ permalink raw reply	[flat|nested] 21+ 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; 21+ 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] 21+ 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; 21+ 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] 21+ 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; 21+ 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] 21+ 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     ` ebiederm
  2018-10-08 15:29       ` Enrico Weigelt, metux IT consult
  2018-10-08 13:54     ` Enrico Weigelt, metux IT consult
  2 siblings, 1 reply; 21+ messages in thread
From: ebiederm @ 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] 21+ 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     ` ebiederm
@ 2018-10-08 13:54     ` Enrico Weigelt, metux IT consult
  2 siblings, 0 replies; 21+ 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] 21+ messages in thread

* Re: Linux 4.19-rc4 released, an apology, and a maintainership note
  2018-10-04 14:57     ` ebiederm
@ 2018-10-08 15:29       ` Enrico Weigelt, metux IT consult
  0 siblings, 0 replies; 21+ 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] 21+ 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; 21+ 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] 21+ messages in thread

end of thread, back to index

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2018-09-17  0:20 ` [...] " Andy Isaacson
2018-09-17  0:23 ` Linux 4.19-rc4 released, " Rene Herman
2018-09-17  6:57 ` opal hart
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
2018-09-30 14:07       ` Martin Steigerwald
2018-09-30 16:27         ` Luke Kenneth Casson Leighton
2018-09-17 12:58 ` Guenter Roeck
2018-09-17 17:09 ` Joe Perches
2018-09-17 21:09 ` Michael Woods
2018-09-18  1:30   ` Pavel Snajdr
2018-09-21 22:13     ` Michael Woods
2018-10-04 14:57     ` ebiederm
2018-10-08 15:29       ` Enrico Weigelt, metux IT consult
2018-10-08 13:54     ` Enrico Weigelt, metux IT consult
2018-10-08 16:36 ` Enrico Weigelt, metux IT consult

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

	# 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 linux-kernel@archiver.kernel.org
	public-inbox-index lkml


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