Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
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
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
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. -- Martin K. Petersen Oracle Linux Engineering
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
On Fri, 2019-09-13 at 16:17 -0300, Mauro Carvalho Chehab wrote: > Em Fri, 13 Sep 2019 11:42:38 -0700 > Joe Perches 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 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]
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
Em Fri, 13 Sep 2019 11:42:38 -0700 Joe Perches escreveu: > On Fri, 2019-09-13 at 15:26 +0100, Rob Herring wrote: > > On Fri, Sep 13, 2019 at 3:12 PM Joe Perches 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 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
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
On Fri, 2019-09-13 at 15:26 +0100, Rob Herring wrote: > On Fri, Sep 13, 2019 at 3:12 PM Joe Perches 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 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
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
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 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, 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-disc...@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > > > > > > > Thanks, > Mauro > ___ > Ksummit-discuss mailing list > ksummit-disc...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
On Fri, Sep 13, 2019 at 3:12 PM Joe Perches 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
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
Em Fri, 13 Sep 2019 08:56:30 -0400 Matthew Wilcox 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, 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-disc...@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > > Thanks, Mauro
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
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.
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
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.
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
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.
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
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.
Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
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.
Re: [PATCH v2 0/3] Maintainer Entry Profiles
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. -- Martin K. Petersen Oracle Linux Engineering Linux SCSI Subsystem Patch Submission Guidelines Martin K. Petersen Release cycles and when to submit patches = Each release cycle consists of: * an 8 week submission window in which new core features and driver updates are added (scsi-queue) * a 2 week merge window where it is customary not to post patches * an 8 week stabilization window before final release where only bug fix patches are merged (scsi-fixes) The submission/stabilization cycle may be shorter or longer than 8 weeks. However, 8 weeks is the most common. Note that the code *submission window* for the *next* kernel release overlaps with the *stabilization window* for the *current* release: +-+-+-+- | Week 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | . +-+-+-+- +-+-+-+ | 4.x merge |4.x stabilization window | 4.x release | | window | rc1 rc2 rc3 rc4 rc5 rc6 rc7 rc8 | | +-+-+-+ | Merge fixes | Big bug fixes.small | Stable| +-+-+-+ +-+-+- |4.x+1 submission window | 4.x+1 merge | 4.x+1 stabili- | | window | zation window | | | rc1 rc2 rc3 ... +-+-+- | Big features/updates..small | Merge fixes | Big bug fixes.. +-+-+- Bug Fixes (4.x/scsi-fixes) ~~ During the two week merge window only fixes related to the merge process or any critical functional deficiences discovered in the newly submitted code will be merged. During the subsequent stabilization window (rc cycle) the expectation is that bug fix patches will become increasingly smaller and simpler. In other words: There may be enough fallout from a merged driver update to justify sending a 5-patch remedial bug fix series during rc1/rc2. But at the end of the rc cycle patches must be trivial one-liners. After the final 4.x has been released, subsequent bug fixes will have to go through the stable-kernel-rules.rst process. New Features/Core Code Changes/Driver Updates (4.x+1/scsi-queue) New features for 4.x+1 should be sent to linux-scsi once the merge window is over. I.e. once rc1 has been released. This ensures there is enough time to undergo several review cycles before the submission window is closed. At the end of the submission window (rc7/rc8) the expectation is that posted patches will be small and fairly simple. No patch series. Only critical patches are merged during the last (rc8) submission window week to ensure sufficient zeroday test robot and linux-next coverage before sending Linus the final pull request. GIT Trees = The SCSI patch submission trees can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git There are two concurrently active branches: * 4.x/scsi-fixes for bug fixes to the current kernel rc * 4.x+1/scsi-queue for new features and driver submissions for the next merge window Both trees are usually based on Linus' 4.x-rc1. Patches accepted into 4.x/scsi-fixes are typically submitted to Linus on a weekly basis. Patches accepted into 4.x+1/scsi-queue are submitted at the beginning of the merge window. It is sometimes necessary to set up a separate 4.x+1/scsi-postmerge branch which contains patches that depend on newly merged functionality in other subsystems such as block or libata. The postmerge tree will be submitted to Linus at the end of the merge window once all external dependencies have been merged. Patch Submission Process * All modifications to files under drivers/scsi should go through the SCSI tree. * Read Documentation/process/submitting-patches.rst * Send the patch or patch series to linux-
[PATCH v2 0/3] Maintainer Entry Profiles
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.st...@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