| Message ID | 156821692280.2951081.18036584954940423225.stgit@dwillia2-desk3.amr.corp.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Maintainer Entry Profiles | expand |
Hi Dan! > At last years Plumbers Conference I proposed the Maintainer Entry > Profile as a document that a maintainer can provide to set contributor > expectations and provide fodder for a discussion between maintainers > about the merits of different maintainer policies. This looks pretty good to me. After the Plumbers session last year I wrote this for SCSI based on a prior version by Christoph. It's gone a bit stale but I'll update it to match your template.
On 9/11/19 4:48 PM, Dan Williams wrote: > At last years Plumbers Conference I proposed the Maintainer Entry > Profile as a document that a maintainer can provide to set contributor > expectations and provide fodder for a discussion between maintainers > about the merits of different maintainer policies. > > For those that did not attend, the goal of the Maintainer Entry Profile, > and the Maintainer Handbook more generally, is to provide a desk > reference for maintainers both new and experienced. The session > introduction was: > > The first rule of kernel maintenance is that there are no hard and > fast rules. That state of affairs is both a blessing and a curse. It > has served the community well to be adaptable to the different > people and different problem spaces that inhabit the kernel > community. However, that variability also leads to inconsistent > experiences for contributors, little to no guidance for new > contributors, and unnecessary stress on current maintainers. There > are quite a few of people who have been around long enough to make > enough mistakes that they have gained some hard earned proficiency. > However if the kernel community expects to keep growing it needs to > be able both scale the maintainers it has and ramp new ones without > necessarily let them make a decades worth of mistakes to learn the > ropes. > > To be clear, the proposed document does not impose or suggest new > rules. Instead it provides an outlet to document the unwritten rules > and policies in effect for each subsystem, and that each subsystem > might decide differently for whatever reason. Any maintainer who reads this might interpret this as an encouragement to establish custom policies. I think one of the conclusions of the Linux Plumbers 2019 edition is that too much diversity is bad and that we need more uniformity across kernel subsystems with regard what is expected from patch contributors. I would appreciate if a summary of https://linuxplumbersconf.org/event/4/contributions/554/attachments/353/584/Reflections__Kernel_Summit_2019.pdf would be integrated in the maintainer handbook. Thanks, Bart.
On 9/11/19 5:40 PM, Martin K. Petersen wrote: > * Do not use custom To: and Cc: for individual patches. We want to see the > whole series, even patches that potentially need to go through a different > subsystem tree. Hi Martin, Thanks for having written this summary. This is very helpful. For the above paragraph, should it be clarified whether that requirement applies to mailing list e-mail addresses only or also to individual e-mail addresses? When using git send-email it is easy to end up with different cc-lists per patch. > * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__") > and does not incur any zeroday test robot complaints. How about adding W=1 to that make command? How about existing drivers that trigger tons of endianness warnings, e.g. qla2xxx? How about requiring that no new warnings are introduced? > * The patch must have a commit message that describes, comprehensively and in > plain English, what the patch does. How about making this requirement more detailed and requiring that not only what has been changed is document but also why that change has been made? > * Patches which have been obsoleted by a later version will be set to > "Superceded" status. Did you perhaps mean "Superseded"? Thanks, Bart.
On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote: > On 9/11/19 5:40 PM, Martin K. Petersen wrote: > > * Do not use custom To: and Cc: for individual patches. We want to see the > > whole series, even patches that potentially need to go through a different > > subsystem tree. That's not currently feasible when cc'ing any vger.kernel.org list as those lists have a maximum email header size and patches that span multiple subsystems can have very long to: and cc: lists. > > * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__") > > and does not incur any zeroday test robot complaints. > > How about adding W=1 to that make command? That's rather too compiler version dependent and new warnings frequently get introduced by new compiler versions. > How about existing drivers that trigger tons of endianness warnings, > e.g. qla2xxx? How about requiring that no new warnings are introduced? Adding a sparse clean C=2 requirement might be useful. > > * The patch must have a commit message that describes, comprehensively and in > > plain English, what the patch does. > > How about making this requirement more detailed and requiring that not > only what has been changed is document but also why that change has been > made? I believe the "why" is rather more important than the "how" and should be the primary thing described in the commit message.
On 9/12/19 8:34 AM, Joe Perches wrote: > On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote: >> On 9/11/19 5:40 PM, Martin K. Petersen wrote: >>> * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__") >>> and does not incur any zeroday test robot complaints. >> >> How about adding W=1 to that make command? > > That's rather too compiler version dependent and new > warnings frequently get introduced by new compiler versions. I've never observed this myself. If a new compiler warning is added to gcc and if it produces warnings that are not useful for kernel code usually Linus or someone else is quick to suppress that warning. Another argument in favor of W=1 is that the formatting of kernel-doc headers is checked only if W=1 is passed to make. Bart.
On Thu, 2019-09-12 at 13:01 -0700, Bart Van Assche wrote: > Another argument in favor of W=1 is that the formatting of kernel-doc > headers is checked only if W=1 is passed to make. Actually, but for the fact there are far too many to generally enable that warning right now, (an x86-64 defconfig has more than 1000) that sounds pretty reasonable to me.
It's easy enough to move the kernel-doc warnings out from under W=1. I only out them there to avoid overwhelming us with new warnings. If they're mostly fixed now, let's make checking them the default. On Thu., Sep. 12, 2019, 16:01 Bart Van Assche, <bvanassche@acm.org> wrote: > On 9/12/19 8:34 AM, Joe Perches wrote: > > On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote: > >> On 9/11/19 5:40 PM, Martin K. Petersen wrote: > >>> * The patch must compile without warnings (make C=1 > CF="-D__CHECK_ENDIAN__") > >>> and does not incur any zeroday test robot complaints. > >> > >> How about adding W=1 to that make command? > > > > That's rather too compiler version dependent and new > > warnings frequently get introduced by new compiler versions. > > I've never observed this myself. If a new compiler warning is added to > gcc and if it produces warnings that are not useful for kernel code > usually Linus or someone else is quick to suppress that warning. > > Another argument in favor of W=1 is that the formatting of kernel-doc > headers is checked only if W=1 is passed to make. > > Bart. > > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss >
Em Fri, 13 Sep 2019 08:56:30 -0400 Matthew Wilcox <willy6545@gmail.com> escreveu: > It's easy enough to move the kernel-doc warnings out from under W=1. I only > out them there to avoid overwhelming us with new warnings. If they're > mostly fixed now, let's make checking them the default. Didn't try doing it kernelwide, but for media we do use W=1 by default, on our CI instance. There's a few warnings at EDAC, but they all seem easy enough to be fixed. So, from my side, I'm all to make W=1 default. Regards, Mauro > > On Thu., Sep. 12, 2019, 16:01 Bart Van Assche, <bvanassche@acm.org> wrote: > > > On 9/12/19 8:34 AM, Joe Perches wrote: > > > On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote: > > >> On 9/11/19 5:40 PM, Martin K. Petersen wrote: > > >>> * The patch must compile without warnings (make C=1 > > CF="-D__CHECK_ENDIAN__") > > >>> and does not incur any zeroday test robot complaints. > > >> > > >> How about adding W=1 to that make command? > > > > > > That's rather too compiler version dependent and new > > > warnings frequently get introduced by new compiler versions. > > > > I've never observed this myself. If a new compiler warning is added to > > gcc and if it produces warnings that are not useful for kernel code > > usually Linus or someone else is quick to suppress that warning. > > > > Another argument in favor of W=1 is that the formatting of kernel-doc > > headers is checked only if W=1 is passed to make. > > > > Bart. > > > > _______________________________________________ > > Ksummit-discuss mailing list > > Ksummit-discuss@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > > Thanks, Mauro
On Fri, Sep 13, 2019 at 3:12 PM Joe Perches <joe@perches.com> wrote: > > On Thu, 2019-09-12 at 13:01 -0700, Bart Van Assche wrote: > > > Another argument in favor of W=1 is that the formatting of kernel-doc > > headers is checked only if W=1 is passed to make. > > Actually, but for the fact there are far too many > to generally enable that warning right now, > (an x86-64 defconfig has more than 1000) > that sounds pretty reasonable to me. It's in the 1000s on arm because W=1 turns on more checks in building .dts files. There are lots of duplicates as most of the dts content is as an include file (e.g. board dts includes soc dts). We could shift the dts checks to W=2 (and what's enabled by W=2 now to 3) I guess. Why not just promote what doesn't give false or still noisy warnings out of W=1 to be the default? Rob
On Fri, Sep 13, 2019 at 10:54:46AM -0300, Mauro Carvalho Chehab wrote: > Em Fri, 13 Sep 2019 08:56:30 -0400 > Matthew Wilcox <willy6545@gmail.com> escreveu: > > > It's easy enough to move the kernel-doc warnings out from under W=1. I only > > out them there to avoid overwhelming us with new warnings. If they're > > mostly fixed now, let's make checking them the default. > > Didn't try doing it kernelwide, but for media we do use W=1 by default, > on our CI instance. > I used to do that as well, but gave up on it since it resulted in lots of warnings from generic kernel include files. I have not tried recently, so maybe that is no longer the case. > There's a few warnings at EDAC, but they all seem easy enough to be > fixed. > Acceptance depends on the maintainer, really. I had patches rejected when trying to fix W=1 warnings, so I no longer do it. > So, from my side, I'm all to make W=1 default. > Seems to me that would require a common agreement that maintainers are expected to accept fixes for problems reported with W=1. Guenter > Regards, > Mauro > > > > > On Thu., Sep. 12, 2019, 16:01 Bart Van Assche, <bvanassche@acm.org> wrote: > > > > > On 9/12/19 8:34 AM, Joe Perches wrote: > > > > On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote: > > > >> On 9/11/19 5:40 PM, Martin K. Petersen wrote: > > > >>> * The patch must compile without warnings (make C=1 > > > CF="-D__CHECK_ENDIAN__") > > > >>> and does not incur any zeroday test robot complaints. > > > >> > > > >> How about adding W=1 to that make command? > > > > > > > > That's rather too compiler version dependent and new > > > > warnings frequently get introduced by new compiler versions. > > > > > > I've never observed this myself. If a new compiler warning is added to > > > gcc and if it produces warnings that are not useful for kernel code > > > usually Linus or someone else is quick to suppress that warning. > > > > > > Another argument in favor of W=1 is that the formatting of kernel-doc > > > headers is checked only if W=1 is passed to make. > > > > > > Bart. > > > > > > _______________________________________________ > > > Ksummit-discuss mailing list > > > Ksummit-discuss@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > > > > > > > Thanks, > Mauro > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
On Fri, 2019-09-13 at 15:26 +0100, Rob Herring wrote: > On Fri, Sep 13, 2019 at 3:12 PM Joe Perches <joe@perches.com> wrote: > > On Thu, 2019-09-12 at 13:01 -0700, Bart Van Assche wrote: > > > > > Another argument in favor of W=1 is that the formatting of kernel-doc > > > headers is checked only if W=1 is passed to make. > > > > Actually, but for the fact there are far too many > > to generally enable that warning right now, > > (an x86-64 defconfig has more than 1000) > > that sounds pretty reasonable to me. > It's in the 1000s on arm because W=1 turns on more checks in building > .dts files. There are lots of duplicates as most of the dts content is > as an include file (e.g. board dts includes soc dts). Yeah, dts[i] files in arm compilations are very noisy at W=1 so moving those message types to W=2 seems sensible. $ { opt="ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnueabi-" ; make $opt clean ; make $opt defconfig ; make $opt W=1 -j4 ; } > arm_make.log 2>&1 $ grep -i -P 'dtsi?:.*warning' arm_make.log | wc -l 69164 Just fyi: for an x86-64 defconfig with gcc 8.3 $ { make clean ; make defconfig ; make -j4 W=1 ; } > make.log 2>&1 There are ~300 W=1 for non kernel-doc -W<foo> warnings. $ grep -i -P -oh '\[\-W[\w\-]+\]' make.log |sort | uniq -c | sort -rn 163 [-Wmissing-prototypes] 69 [-Wunused-but-set-variable] 16 [-Wempty-body] 10 [-Wtype-limits] 6 [-Woverride-init] 2 [-Wstringop-truncation] 2 [-Wcast-function-type] 1 [-Wunused-but-set-parameter] And there are ~1000 kernel-doc only messages in various files $ grep -i 'function parameter' make.log | cut -f1 -d: | sort | uniq -c 6 arch/x86/events/intel/pt.c 2 arch/x86/kernel/apic/apic.c 10 arch/x86/kernel/cpu/mtrr/generic.c 5 arch/x86/kernel/crash_dump_64.c 1 arch/x86/kernel/i8259.c 3 arch/x86/kernel/smpboot.c 3 arch/x86/kernel/tsc.c 2 arch/x86/kernel/uprobes.c 1 arch/x86/lib/cmdline.c 1 arch/x86/lib/insn.c 2 arch/x86/lib/insn-eval.c 4 arch/x86/lib/msr.c 2 arch/x86/lib/usercopy_64.c 1 arch/x86/mm/pat.c 13 arch/x86/mm/pgtable.c 1 arch/x86/pci/i386.c 2 arch/x86/power/cpu.c 2 arch/x86/power/hibernate.c 8 certs/system_keyring.c 4 crypto/asymmetric_keys/asymmetric_type.c 3 crypto/asymmetric_keys/pkcs7_trust.c 16 crypto/jitterentropy.c 3 drivers/acpi/acpi_apd.c 3 drivers/acpi/bus.c 2 drivers/acpi/cppc_acpi.c 5 drivers/acpi/device_sysfs.c 2 drivers/acpi/dock.c 2 drivers/acpi/nvs.c 1 drivers/acpi/pci_root.c 5 drivers/acpi/property.c 4 drivers/acpi/sleep.c 7 drivers/acpi/utils.c 1 drivers/ata/libata-acpi.c 2 drivers/ata/libata-pmp.c 6 drivers/ata/libata-transport.c 4 drivers/ata/pata_amd.c 4 drivers/base/attribute_container.c 1 drivers/base/devcon.c 3 drivers/base/platform-msi.c 3 drivers/base/power/runtime.c 5 drivers/base/power/wakeup.c 2 drivers/char/agp/backend.c 3 drivers/char/agp/generic.c 2 drivers/clk/clk.c 1 drivers/clk/clk-fixed-factor.c 1 drivers/clk/clk-fixed-rate.c 3 drivers/connector/cn_proc.c 31 drivers/cpufreq/cpufreq.c 3 drivers/cpufreq/cpufreq_governor.c 7 drivers/cpufreq/freq_table.c 1 drivers/cpufreq/intel_pstate.c 6 drivers/cpuidle/sysfs.c 1 drivers/dma-buf/dma-buf.c 1 drivers/dma-buf/dma-fence-chain.c 6 drivers/dma/dmaengine.c 7 drivers/firewire/init_ohci1394_dma.c 2 drivers/firmware/efi/memmap.c 1 drivers/firmware/efi/vars.c 20 drivers/gpu/drm/drm_agpsupport.c 8 drivers/hid/hid-core.c 3 drivers/hid/hid-quirks.c 5 drivers/hid/usbhid/hid-pidff.c 3 drivers/input/mouse/synaptics.c 2 drivers/iommu/amd_iommu_init.c 2 drivers/iommu/dmar.c 1 drivers/iommu/intel-pasid.c 1 drivers/iommu/iommu.c 2 drivers/leds/led-class.c 2 drivers/mailbox/pcc.c 6 drivers/net/ethernet/intel/e1000/e1000_hw.c 21 drivers/net/ethernet/intel/e1000/e1000_main.c 1 drivers/net/ethernet/intel/e1000e/80003es2lan.c 6 drivers/net/ethernet/intel/e1000e/ich8lan.c 42 drivers/net/ethernet/intel/e1000e/netdev.c 3 drivers/net/ethernet/intel/e1000e/phy.c 2 drivers/net/ethernet/intel/e1000e/ptp.c 1 drivers/net/netconsole.c 3 drivers/net/phy/mdio-boardinfo.c 2 drivers/net/phy/mdio_device.c 2 drivers/pci/ats.c 3 drivers/pci/hotplug/acpi_pcihp.c 4 drivers/pci/pcie/aer.c 2 drivers/pci/pcie/pme.c 1 drivers/pci/setup-bus.c 1 drivers/pci/vc.c 22 drivers/pcmcia/cistpl.c 13 drivers/pcmcia/pcmcia_cis.c 13 drivers/pcmcia/pcmcia_resource.c 11 drivers/pcmcia/rsrc_nonstatic.c 1 drivers/pnp/system.c 11 drivers/rtc/interface.c 3 drivers/rtc/sysfs.c 2 drivers/thermal/step_wise.c 2 drivers/thermal/user_space.c 6 drivers/tty/n_tty.c 4 drivers/tty/pty.c 7 drivers/tty/tty_audit.c 7 drivers/tty/tty_baudrate.c 13 drivers/tty/tty_buffer.c 25 drivers/tty/tty_io.c 5 drivers/tty/tty_jobctrl.c 6 drivers/tty/tty_ldisc.c 6 drivers/tty/tty_port.c 5 drivers/tty/vt/consolemap.c 4 drivers/tty/vt/vt.c 3 drivers/tty/vt/vt_ioctl.c 12 drivers/usb/common/debug.c 1 drivers/usb/host/pci-quirks.c 1 drivers/usb/host/xhci.c 6 drivers/usb/host/xhci-mem.c 2 drivers/video/backlight/backlight.c 1 drivers/video/fbdev/core/fbmon.c 2 drivers/video/fbdev/core/fb_notify.c 7 fs/devpts/inode.c 4 fs/direct-io.c 3 fs/eventpoll.c 6 fs/fat/dir.c 3 fs/fat/misc.c 6 fs/fat/nfs.c 4 fs/fs_context.c 1 fs/fs_parser.c 2 fs/fs-writeback.c 5 fs/ioctl.c 1 fs/libfs.c 3 fs/namespace.c 2 fs/nfs_common/grace.c 2 fs/open.c 3 fs/posix_acl.c 1 fs/proc/proc_net.c 2 fs/proc/vmcore.c 2 fs/read_write.c 1 fs/super.c 5 fs/xattr.c 2 kernel/cgroup/cpuset.c 1 kernel/cpu.c 4 kernel/events/core.c 2 kernel/events/hw_breakpoint.c 5 kernel/fork.c 27 kernel/irq/irqdomain.c 3 kernel/irq/matrix.c 1 kernel/kprobes.c 5 kernel/locking/rtmutex.c 1 kernel/notifier.c 3 kernel/power/main.c 2 kernel/power/qos.c 51 kernel/power/snapshot.c 2 kernel/power/suspend.c 14 kernel/power/swap.c 1 kernel/reboot.c 4 kernel/seccomp.c 2 kernel/stacktrace.c 4 kernel/time/alarmtimer.c 1 kernel/time/clockevents.c 4 kernel/time/posix-cpu-timers.c 1 kernel/time/tick-broadcast.c 6 kernel/time/tick-oneshot.c 3 kernel/time/tick-sched.c 3 kernel/time/timeconv.c 23 kernel/time/timekeeping.c 9 kernel/trace/ring_buffer.c 8 kernel/trace/trace_events_filter.c 2 kernel/trace/trace_events_trigger.c 1 kernel/trace/trace_seq.c 1 lib/argv_split.c 1 lib/cpumask.c 5 lib/genalloc.c 4 lib/iov_iter.c 2 lib/nlattr.c 3 lib/percpu_counter.c 6 lib/radix-tree.c 2 lib/scatterlist.c 3 lib/win_minmax.c 1 mm/compaction.c 2 mm/oom_kill.c 1 mm/page_vma_mapped.c 2 mm/swap_state.c 1 mm/vmalloc.c 1 mm/vmscan.c 8 net/ipv4/cipso_ipv4.c 3 net/ipv4/ipmr.c 1 net/ipv4/tcp_input.c 5 net/ipv4/tcp_output.c 2 net/ipv4/tcp_timer.c 3 net/ipv4/udp.c 4 net/ipv6/calipso.c 1 net/ipv6/exthdrs.c 1 net/ipv6/ip6_output.c 3 net/ipv6/udp.c 1 net/mac80211/tx.c 5 net/netlabel/netlabel_calipso.c 2 net/netlabel/netlabel_domainhash.c 3 net/sched/ematch.c 1 net/socket.c 1 net/wireless/radiotap.c 4 net/wireless/reg.c 6 security/commoncap.c 1 security/lsm_audit.c 12 security/selinux/avc.c 7 security/selinux/netlabel.c 2 security/selinux/netport.c 4 security/selinux/ss/mls.c 34 security/selinux/ss/services.c 3 sound/hda/hdac_bus.c 1 sound/hda/hdac_component.c 2 sound/hda/hdac_controller.c 10 sound/hda/hdac_device.c 2 sound/hda/hdac_stream.c 1 sound/pci/hda/hda_codec.c
Em Fri, 13 Sep 2019 11:42:38 -0700 Joe Perches <joe@perches.com> escreveu: > On Fri, 2019-09-13 at 15:26 +0100, Rob Herring wrote: > > On Fri, Sep 13, 2019 at 3:12 PM Joe Perches <joe@perches.com> wrote: > > > On Thu, 2019-09-12 at 13:01 -0700, Bart Van Assche wrote: > > > > > > > Another argument in favor of W=1 is that the formatting of kernel-doc > > > > headers is checked only if W=1 is passed to make. > > > > > > Actually, but for the fact there are far too many > > > to generally enable that warning right now, > > > (an x86-64 defconfig has more than 1000) > > > that sounds pretty reasonable to me. > > > It's in the 1000s on arm because W=1 turns on more checks in building > > .dts files. There are lots of duplicates as most of the dts content is > > as an include file (e.g. board dts includes soc dts). > > Yeah, dts[i] files in arm compilations are very noisy at W=1 > so moving those message types to W=2 seems sensible. > > $ { opt="ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnueabi-" ; make $opt clean ; make $opt defconfig ; make $opt W=1 -j4 ; } > arm_make.log 2>&1 > > $ grep -i -P 'dtsi?:.*warning' arm_make.log | wc -l > 69164 Yeah, makes sense moving them to W=2, or to make them somehow produce less noise. > Just fyi: for an x86-64 defconfig with gcc 8.3 > > $ { make clean ; make defconfig ; make -j4 W=1 ; } > make.log 2>&1 > > There are ~300 W=1 for non kernel-doc -W<foo> warnings. > > $ grep -i -P -oh '\[\-W[\w\-]+\]' make.log |sort | uniq -c | sort -rn > 163 [-Wmissing-prototypes] > 69 [-Wunused-but-set-variable] > 16 [-Wempty-body] > 10 [-Wtype-limits] > 6 [-Woverride-init] > 2 [-Wstringop-truncation] > 2 [-Wcast-function-type] > 1 [-Wunused-but-set-parameter] On my eyes, it doesn't sound too much. I suspect that, with gcc-9, it should produce more warnings, though. Perhaps we could "promote" most of those to W=0. > > And there are ~1000 kernel-doc only messages in various files A significant amount of those warnings appear with "make htmldocs". Not having the kernel-doc warning as part of W=0 helps to make very hard to have them cleared. IMHO, those should be enabled by default with W=0, at least for the files that are included on some kernel-doc tag. I mean, perhaps, when W=0, Kernel build could run: $ ./scripts/kernel-doc -none $(git grep kernel-doc:: Documentation/|cut -d: -f4-|sort|uniq|grep -vE "\bsource\b") That produces 165 warnings (against v5.3-rc4 + media -next patches). Thanks, Mauro
On Fri, 2019-09-13 at 16:17 -0300, Mauro Carvalho Chehab wrote: > Em Fri, 13 Sep 2019 11:42:38 -0700 > Joe Perches <joe@perches.com> escreveu: [] > > Just fyi: for an x86-64 defconfig with gcc 8.3 > > > > $ { make clean ; make defconfig ; make -j4 W=1 ; } > make.log 2>&1 > > > > There are ~300 W=1 for non kernel-doc -W<foo> warnings. > > > > $ grep -i -P -oh '\[\-W[\w\-]+\]' make.log |sort | uniq -c | sort -rn > > 163 [-Wmissing-prototypes] > > 69 [-Wunused-but-set-variable] > > 16 [-Wempty-body] > > 10 [-Wtype-limits] > > 6 [-Woverride-init] > > 2 [-Wstringop-truncation] > > 2 [-Wcast-function-type] > > 1 [-Wunused-but-set-parameter] > > On my eyes, it doesn't sound too much. In general, I agree and most of these are pretty trivial to remove. It'd just take some time to remove most of the missing-prototypes and unused-but-set warnings before being able to enable the warnings at the default W=0. > I suspect that, > with gcc-9, it should produce more warnings, though. It doesn't though. At least not so far as I can tell. gcc-9.1 produces the same output. $ { make clean ; make defconfig ; make CC=/usr/bin/gcc-9 -j4 W=1 V=1 ; } > make_gcc9.log 2>&1 $ grep -i -P -oh '\[\-W[\w\-]+\]' make_gcc9.log | sort | uniq -c | sort -rn 163 [-Wmissing-prototypes] 69 [-Wunused-but-set-variable] 16 [-Wempty-body] 10 [-Wtype-limits] 6 [-Woverride-init] 2 [-Wstringop-truncation] 2 [-Wcast-function-type] 1 [-Wunused-but-set-parameter]
Hi Bart, > On 9/11/19 5:40 PM, Martin K. Petersen wrote: >> * Do not use custom To: and Cc: for individual patches. We want to see the >> whole series, even patches that potentially need to go through a different >> subsystem tree. > > Thanks for having written this summary. This is very helpful. For the > above paragraph, should it be clarified whether that requirement > applies to mailing list e-mail addresses only or also to individual > e-mail addresses? When using git send-email it is easy to end up with > different cc-lists per patch. I prefer to have the entire series sent to linux-scsi or target-devel. It wouldn't be so bad if discussions about the merits of a tree-wide change consistently happened in responses to the cover letter. But more often than not discussion happens in response to a patch touching a different subsystem and therefore in a mail exchange that doesn't end up on linux-scsi. >> * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__") >> and does not incur any zeroday test robot complaints. > > How about adding W=1 to that make command? > > How about existing drivers that trigger tons of endianness warnings, > e.g. qla2xxx? How about requiring that no new warnings are introduced? This was in response to a driver submission (for a different driver) around the time this doc was written. The problem is that it's sometimes hard to distinguish new warnings from old ones. I'm all for requiring that no new warnings are introduced. >> * The patch must have a commit message that describes, >> comprehensively and in plain English, what the patch does. > > How about making this requirement more detailed and requiring that not > only what has been changed is document but also why that change has > been made? I'd really like all this patch submission guideline material to live in Documentation/process. But yes.
On 9/11/19 5:40 PM, Martin K. Petersen wrote: > After the Plumbers session last year I wrote this for SCSI based on a > prior version by Christoph. It's gone a bit stale but I'll update it to > match your template. > Hi Martin, The Maintainer profile is very helpful. Are you planning to send another version and address Bart's comments? Thanks, Roman
Changes since v1 [1]: - Simplify the profile to a hopefully non-controversial set of attributes that address the most common sources of contributor confusion, or maintainer frustration. - Rename "Subsystem Profile" to "Maintainer Entry Profile". Not every entry in MAINTAINERS represents a full subsystem. There may be driver local considerations to communicate to a submitter in addition to wider subsystem guidelines. - Delete the old P: tag in MAINTAINERS rather than convert to a new E: tag (Joe Perches). [1]: http://lore.kernel.org/r/154225759358.2499188.15268218778137905050.stgit@dwillia2-desk3.amr.corp.intel.com --- At last years Plumbers Conference I proposed the Maintainer Entry Profile as a document that a maintainer can provide to set contributor expectations and provide fodder for a discussion between maintainers about the merits of different maintainer policies. For those that did not attend, the goal of the Maintainer Entry Profile, and the Maintainer Handbook more generally, is to provide a desk reference for maintainers both new and experienced. The session introduction was: The first rule of kernel maintenance is that there are no hard and fast rules. That state of affairs is both a blessing and a curse. It has served the community well to be adaptable to the different people and different problem spaces that inhabit the kernel community. However, that variability also leads to inconsistent experiences for contributors, little to no guidance for new contributors, and unnecessary stress on current maintainers. There are quite a few of people who have been around long enough to make enough mistakes that they have gained some hard earned proficiency. However if the kernel community expects to keep growing it needs to be able both scale the maintainers it has and ramp new ones without necessarily let them make a decades worth of mistakes to learn the ropes. To be clear, the proposed document does not impose or suggest new rules. Instead it provides an outlet to document the unwritten rules and policies in effect for each subsystem, and that each subsystem might decide differently for whatever reason. --- Dan Williams (3): MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Maintainer Handbook: Maintainer Entry Profile libnvdimm, MAINTAINERS: Maintainer Entry Profile Documentation/maintainer/index.rst | 1 .../maintainer/maintainer-entry-profile.rst | 99 ++++++++++++++++++++ Documentation/nvdimm/maintainer-entry-profile.rst | 64 +++++++++++++ MAINTAINERS | 20 ++-- 4 files changed, 175 insertions(+), 9 deletions(-) create mode 100644 Documentation/maintainer/maintainer-entry-profile.rst create mode 100644 Documentation/nvdimm/maintainer-entry-profile.rst