* [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles @ 2019-09-11 15:48 Dan Williams 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams ` (4 more replies) 0 siblings, 5 replies; 82+ messages in thread From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw) To: linux-kernel Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, Steve French, Vishal Verma, Mauro Carvalho Chehab, Dmitry Vyukov, Tobin C. Harding 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 _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile 2019-09-11 15:48 [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams @ 2019-09-11 15:48 ` Dan Williams 2019-09-13 15:37 ` Mauro Carvalho Chehab 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: " Dan Williams ` (3 subsequent siblings) 4 siblings, 1 reply; 82+ messages in thread From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw) To: linux-kernel; +Cc: vishal.l.verma, ksummit-discuss, linux-nvdimm Fixup some P: entries to be M: and delete the others that do not include an email address. The P: tag will be used to indicate the location of a Profile for a given MAINTAINERS entry. Cc: Joe Perches <joe@perches.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- MAINTAINERS | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index e7a47b5210fd..3f171339df53 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -76,7 +76,6 @@ trivial patch so apply some common sense. Descriptions of section entries: - P: Person (obsolete) M: Mail patches to: FullName <address@domain> R: Designated reviewer: FullName <address@domain> These reviewers should be CCed on patches. @@ -811,7 +810,7 @@ S: Orphan F: drivers/usb/gadget/udc/amd5536udc.* AMD GEODE PROCESSOR/CHIPSET SUPPORT -P: Andres Salomon <dilinger@queued.net> +M: Andres Salomon <dilinger@queued.net> L: linux-geode@lists.infradead.org (moderated for non-subscribers) W: http://www.amd.com/us-en/ConnectivitySolutions/TechnicalResources/0,,50_2334_2452_11363,00.html S: Supported @@ -10085,7 +10084,6 @@ F: drivers/staging/media/tegra-vde/ MEDIA INPUT INFRASTRUCTURE (V4L/DVB) M: Mauro Carvalho Chehab <mchehab@kernel.org> -P: LinuxTV.org Project L: linux-media@vger.kernel.org W: https://linuxtv.org Q: http://patchwork.kernel.org/project/linux-media/list/ @@ -13452,7 +13450,6 @@ S: Maintained F: arch/mips/ralink RALINK RT2X00 WIRELESS LAN DRIVER -P: rt2x00 project M: Stanislaw Gruszka <sgruszka@redhat.com> M: Helmut Schaa <helmut.schaa@googlemail.com> L: linux-wireless@vger.kernel.org @@ -13787,7 +13784,6 @@ S: Supported F: drivers/net/ethernet/rocker/ ROCKETPORT DRIVER -P: Comtrol Corp. W: http://www.comtrol.com S: Maintained F: Documentation/driver-api/serial/rocket.rst @@ -14668,15 +14664,13 @@ F: drivers/video/fbdev/simplefb.c F: include/linux/platform_data/simplefb.h SIMTEC EB110ATX (Chalice CATS) -P: Ben Dooks -P: Vincent Sanders <vince@simtec.co.uk> +M: Vincent Sanders <vince@simtec.co.uk> M: Simtec Linux Team <linux@simtec.co.uk> W: http://www.simtec.co.uk/products/EB110ATX/ S: Supported SIMTEC EB2410ITX (BAST) -P: Ben Dooks -P: Vincent Sanders <vince@simtec.co.uk> +M: Vincent Sanders <vince@simtec.co.uk> M: Simtec Linux Team <linux@simtec.co.uk> W: http://www.simtec.co.uk/products/EB2410ITX/ S: Supported _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams @ 2019-09-13 15:37 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-13 15:37 UTC (permalink / raw) To: Dan Williams; +Cc: vishal.l.verma, linux-kernel, ksummit-discuss, linux-nvdimm Em Wed, 11 Sep 2019 08:48:48 -0700 Dan Williams <dan.j.williams@intel.com> escreveu: > Fixup some P: entries to be M: and delete the others that do not include an > email address. The P: tag will be used to indicate the location of a > Profile for a given MAINTAINERS entry. > > Cc: Joe Perches <joe@perches.com> > Signed-off-by: Dan Williams <dan.j.williams@intel.com> > --- > MAINTAINERS | 12 +++--------- > 1 file changed, 3 insertions(+), 9 deletions(-) > ... > MEDIA INPUT INFRASTRUCTURE (V4L/DVB) > M: Mauro Carvalho Chehab <mchehab@kernel.org> > -P: LinuxTV.org Project > L: linux-media@vger.kernel.org > W: https://linuxtv.org > Q: http://patchwork.kernel.org/project/linux-media/list/ > @@ -13452,7 +13450,6 @@ S: Maintained > F: arch/mips/ralink Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Thanks, Mauro _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile 2019-09-11 15:48 [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams @ 2019-09-11 15:48 ` Dan Williams 2019-09-16 12:35 ` Jani Nikula 2019-10-01 13:55 ` Jonathan Corbet 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams ` (2 subsequent siblings) 4 siblings, 2 replies; 82+ messages in thread From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw) To: linux-kernel Cc: vishal.l.verma, ksummit-discuss, Greg Kroah-Hartman, linux-nvdimm, Dmitry Vyukov, Mauro Carvalho Chehab, Steve French, Tobin C. Harding As presented at the 2018 Linux Plumbers conference [1], the Maintainer Entry Profile (formerly Subsystem Profile) is proposed as a way to reduce friction between committers and maintainers and encourage conversations amongst maintainers about common best practices. While coding-style, submit-checklist, and submitting-drivers lay out some common expectations there remain local customs and maintainer preferences that vary by subsystem. The profile contains short answers to some of the common policy questions a contributor might have that are local to the subsystem / device-driver, or otherwise not covered by the top-level process documents. Overview: General introduction to how the subsystem operates Submit Checklist Addendum: Mechanical items that gate submission staging Key Cycle Dates: - Last -rc for new feature submissions: Expected lead time for submissions - Last -rc to merge features: Deadline for merge decisions Coding Style Addendum: Clarifications of local style preferences Resubmit Cadence: When to ping the maintainer Checkpatch / Style Cleanups: Policy on pure cleanup patches See Documentation/maintainer/maintainer-entry-profile.rst for more details, and a follow-on example profile for the libnvdimm subsystem. [1]: https://linuxplumbersconf.org/event/2/contributions/59/ Cc: Jonathan Corbet <corbet@lwn.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Steve French <stfrench@microsoft.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Tobin C. Harding <me@tobin.cc> Cc: Olof Johansson <olof@lixom.net> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Joe Perches <joe@perches.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- Documentation/maintainer/index.rst | 1 .../maintainer/maintainer-entry-profile.rst | 99 ++++++++++++++++++++ MAINTAINERS | 4 + 3 files changed, 104 insertions(+) create mode 100644 Documentation/maintainer/maintainer-entry-profile.rst diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst index 56e2c09dfa39..d904e74e1159 100644 --- a/Documentation/maintainer/index.rst +++ b/Documentation/maintainer/index.rst @@ -12,4 +12,5 @@ additions to this manual. configure-git rebasing-and-merging pull-requests + maintainer-entry-profile diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst new file mode 100644 index 000000000000..aaedf4d6dbf7 --- /dev/null +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -0,0 +1,99 @@ +.. _maintainerentryprofile: + +Maintainer Entry Profile +======================== + +The Maintainer Entry Profile supplements the top-level process documents +(coding-style, submitting-patches...) with subsystem/device-driver-local +customs as well as details about the patch submission lifecycle. A +contributor uses this document to level set their expectations and avoid +common mistakes, maintainers may use these profiles to look across +subsystems for opportunities to converge on common practices. + + +Overview +-------- +Provide an introduction to how the subsystem operates. While MAINTAINERS +tells the contributor where to send patches for which files, it does not +convey other subsystem-local infrastructure and mechanisms that aid +development. +Example questions to consider: +- Are there notifications when patches are applied to the local tree, or + merged upstream? +- Does the subsystem have a patchwork instance? +- Any bots or CI infrastructure that watches the list? +- Git branches that are pulled into -next? +- What branch should contributors submit against? +- Links to any other Maintainer Entry Profiles? For example a + device-driver may point to an entry for its parent subsystem. This makes + the contributor aware of obligations a maintainer may have have for + other maintainers in the submission chain. + + +Submit Checklist Addendum +------------------------- +List mandatory and advisory criteria, beyond the common "submit-checklist", +for a patch to be considered healthy enough for maintainer attention. +For example: "pass checkpatch.pl with no errors, or warning. Pass the +unit test detailed at $URI". + + +Key Cycle Dates +--------------- +One of the common misunderstandings of submitters is that patches can be +sent at any time before the merge window closes and can still be +considered for the next -rc1. The reality is that most patches need to +be settled in soaking in linux-next in advance of the merge window +opening. Clarify for the submitter the key dates (in terms rc release +week) that patches might considered for merging and when patches need to +wait for the next -rc. At a minimum: +- Last -rc for new feature submissions: + New feature submissions targeting the next merge window should have + their first posting for consideration before this point. Patches that + are submitted after this point should be clear that they are targeting + the NEXT+1 merge window, or should come with sufficient justification + why they should be considered on an expedited schedule. A general + guideline is to set expectation with contributors that new feature + submissions should appear before -rc5. + +- Last -rc to merge features: Deadline for merge decisions + Indicate to contributors the point at which an as yet un-applied patch + set will need to wait for the NEXT+1 merge window. Of course there is no + obligation to ever except any given patchset, but if the review has not + concluded by this point the expectation the contributor should wait and + resubmit for the following merge window. + +Optional: +- First -rc at which the development baseline branch, listed in the + overview section, should be considered ready for new submissions. + + +Coding Style Addendum +--------------------- +While the top-level "coding-style" document covers most style +considerations there are still discrepancies and local preferences +across subsystems. If a submitter should be aware of incremental / local +style guidelines like x-mas tree variable declarations, indentation +for multi line statements, function definition style, etc., list them +here. + + +Review Cadence +-------------- +One of the largest sources of contributor angst is how soon to ping +after a patchset has been posted without receiving any feedback. In +addition to specifying how long to wait before a resubmission this +section can also indicate a preferred style of update like, resend the +full series, or privately send a reminder email. This section might also +list how review works for this code area and methods to get feedback +that are not directly from the maintainer. + + +Style Cleanup Patches +--------------------- +For subsystems with long standing code bases it is reasonable to decline +to accept pure coding-style fixup patches. This is where you can let +contributors know "Standalone style-cleanups are welcome", +"Style-cleanups to existing code only welcome with other feature +changes", or “Standalone style-cleanups to existing code are not +welcome". diff --git a/MAINTAINERS b/MAINTAINERS index 3f171339df53..e5d111a86e61 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -98,6 +98,10 @@ Descriptions of section entries: Obsolete: Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that. + P: Subsystem Profile document for more details submitting + patches to the given subsystem. This is either an in-tree file, + or a URI. See Documentation/maintainer/maintainer-entry-profile.rst + for details. F: Files and directories with wildcard patterns. A trailing slash includes all files and subdirectory files. F: drivers/net/ all files in and below drivers/net _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: " Dan Williams @ 2019-09-16 12:35 ` Jani Nikula 2019-10-01 13:55 ` Jonathan Corbet 1 sibling, 0 replies; 82+ messages in thread From: Jani Nikula @ 2019-09-16 12:35 UTC (permalink / raw) To: Dan Williams, linux-kernel Cc: ksummit-discuss, linux-nvdimm, vishal.l.verma, Steve French, Greg Kroah-Hartman, Mauro Carvalho Chehab, Dmitry Vyukov, Tobin C. Harding On Wed, 11 Sep 2019, Dan Williams <dan.j.williams@intel.com> wrote: > As presented at the 2018 Linux Plumbers conference [1], the Maintainer > Entry Profile (formerly Subsystem Profile) is proposed as a way to reduce > friction between committers and maintainers and encourage conversations > amongst maintainers about common best practices. While coding-style, > submit-checklist, and submitting-drivers lay out some common expectations > there remain local customs and maintainer preferences that vary by > subsystem. > > The profile contains short answers to some of the common policy questions a > contributor might have that are local to the subsystem / device-driver, or > otherwise not covered by the top-level process documents. > > Overview: General introduction to how the subsystem operates > Submit Checklist Addendum: Mechanical items that gate submission staging > Key Cycle Dates: > - Last -rc for new feature submissions: Expected lead time for submissions > - Last -rc to merge features: Deadline for merge decisions > Coding Style Addendum: Clarifications of local style preferences > Resubmit Cadence: When to ping the maintainer > Checkpatch / Style Cleanups: Policy on pure cleanup patches > > See Documentation/maintainer/maintainer-entry-profile.rst for more details, > and a follow-on example profile for the libnvdimm subsystem. > > [1]: https://linuxplumbersconf.org/event/2/contributions/59/ > > Cc: Jonathan Corbet <corbet@lwn.net> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Mauro Carvalho Chehab <mchehab@kernel.org> > Cc: Steve French <stfrench@microsoft.com> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Tobin C. Harding <me@tobin.cc> > Cc: Olof Johansson <olof@lixom.net> > Cc: Martin K. Petersen <martin.petersen@oracle.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Joe Perches <joe@perches.com> > Cc: Dmitry Vyukov <dvyukov@google.com> > Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> > Signed-off-by: Dan Williams <dan.j.williams@intel.com> > --- > Documentation/maintainer/index.rst | 1 > .../maintainer/maintainer-entry-profile.rst | 99 ++++++++++++++++++++ > MAINTAINERS | 4 + > 3 files changed, 104 insertions(+) > create mode 100644 Documentation/maintainer/maintainer-entry-profile.rst > > diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst > index 56e2c09dfa39..d904e74e1159 100644 > --- a/Documentation/maintainer/index.rst > +++ b/Documentation/maintainer/index.rst > @@ -12,4 +12,5 @@ additions to this manual. > configure-git > rebasing-and-merging > pull-requests > + maintainer-entry-profile > > diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst > new file mode 100644 > index 000000000000..aaedf4d6dbf7 > --- /dev/null > +++ b/Documentation/maintainer/maintainer-entry-profile.rst > @@ -0,0 +1,99 @@ > +.. _maintainerentryprofile: > + > +Maintainer Entry Profile > +======================== > + > +The Maintainer Entry Profile supplements the top-level process documents > +(coding-style, submitting-patches...) with subsystem/device-driver-local > +customs as well as details about the patch submission lifecycle. A > +contributor uses this document to level set their expectations and avoid > +common mistakes, maintainers may use these profiles to look across > +subsystems for opportunities to converge on common practices. In general I think we're already pretty good at adding and accumulating documentation, but not so much cleaning up existing and outright throwing out obsolete documentation. 'wc -l Documentation/process/*' says we already have 11k lines of generic process documentation. I would much rather see a streamlined and friendly guide to contributing to the kernel than more rules, and driver/subsystem specific rules at that. I would much rather get the feeling from submissions that the long tail of contributors have actually read and understood the most relevant parts of Documentation/process. I'm pretty sure *I* haven't read all of Documentation/process. My fear is that the entry profiles will only be helpful to the contributors that already "get it". It may be helpful to the maintainers in the sense that they can reply to patches with a pointer to the relevant hoops to jump through. --- Even so, if this gets merged, I'll probably add something helpful for drm and/or i915 contributors. But what's the buy-in across the kernel? If my grep serves me right, there are something like 2000+ entries in MAINTAINERS. If 10% of them adds a profile, that's a fairly serious amount of documentation. But can you actually expect more than a handful of subsystems/drivers to add a profile? Then what's the coverage? For reference, I've added or promoted adding the B: and C: entries to MAINTAINERS. Various subsystems and drivers are really picky about where and how they want bugs reported; in particular some folks only accept email. Yet networking is the only one to indicate the email preference in MAINTAINERS. And adding that is a one line change. (There are 19 B: entries and 7 C: entries in total.) BR, Jani. > + > + > +Overview > +-------- > +Provide an introduction to how the subsystem operates. While MAINTAINERS > +tells the contributor where to send patches for which files, it does not > +convey other subsystem-local infrastructure and mechanisms that aid > +development. > +Example questions to consider: > +- Are there notifications when patches are applied to the local tree, or > + merged upstream? > +- Does the subsystem have a patchwork instance? > +- Any bots or CI infrastructure that watches the list? > +- Git branches that are pulled into -next? > +- What branch should contributors submit against? > +- Links to any other Maintainer Entry Profiles? For example a > + device-driver may point to an entry for its parent subsystem. This makes > + the contributor aware of obligations a maintainer may have have for > + other maintainers in the submission chain. > + > + > +Submit Checklist Addendum > +------------------------- > +List mandatory and advisory criteria, beyond the common "submit-checklist", > +for a patch to be considered healthy enough for maintainer attention. > +For example: "pass checkpatch.pl with no errors, or warning. Pass the > +unit test detailed at $URI". > + > + > +Key Cycle Dates > +--------------- > +One of the common misunderstandings of submitters is that patches can be > +sent at any time before the merge window closes and can still be > +considered for the next -rc1. The reality is that most patches need to > +be settled in soaking in linux-next in advance of the merge window > +opening. Clarify for the submitter the key dates (in terms rc release > +week) that patches might considered for merging and when patches need to > +wait for the next -rc. At a minimum: > +- Last -rc for new feature submissions: > + New feature submissions targeting the next merge window should have > + their first posting for consideration before this point. Patches that > + are submitted after this point should be clear that they are targeting > + the NEXT+1 merge window, or should come with sufficient justification > + why they should be considered on an expedited schedule. A general > + guideline is to set expectation with contributors that new feature > + submissions should appear before -rc5. > + > +- Last -rc to merge features: Deadline for merge decisions > + Indicate to contributors the point at which an as yet un-applied patch > + set will need to wait for the NEXT+1 merge window. Of course there is no > + obligation to ever except any given patchset, but if the review has not > + concluded by this point the expectation the contributor should wait and > + resubmit for the following merge window. > + > +Optional: > +- First -rc at which the development baseline branch, listed in the > + overview section, should be considered ready for new submissions. > + > + > +Coding Style Addendum > +--------------------- > +While the top-level "coding-style" document covers most style > +considerations there are still discrepancies and local preferences > +across subsystems. If a submitter should be aware of incremental / local > +style guidelines like x-mas tree variable declarations, indentation > +for multi line statements, function definition style, etc., list them > +here. > + > + > +Review Cadence > +-------------- > +One of the largest sources of contributor angst is how soon to ping > +after a patchset has been posted without receiving any feedback. In > +addition to specifying how long to wait before a resubmission this > +section can also indicate a preferred style of update like, resend the > +full series, or privately send a reminder email. This section might also > +list how review works for this code area and methods to get feedback > +that are not directly from the maintainer. > + > + > +Style Cleanup Patches > +--------------------- > +For subsystems with long standing code bases it is reasonable to decline > +to accept pure coding-style fixup patches. This is where you can let > +contributors know "Standalone style-cleanups are welcome", > +"Style-cleanups to existing code only welcome with other feature > +changes", or “Standalone style-cleanups to existing code are not > +welcome". > diff --git a/MAINTAINERS b/MAINTAINERS > index 3f171339df53..e5d111a86e61 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -98,6 +98,10 @@ Descriptions of section entries: > Obsolete: Old code. Something tagged obsolete generally means > it has been replaced by a better system and you > should be using that. > + P: Subsystem Profile document for more details submitting > + patches to the given subsystem. This is either an in-tree file, > + or a URI. See Documentation/maintainer/maintainer-entry-profile.rst > + for details. > F: Files and directories with wildcard patterns. > A trailing slash includes all files and subdirectory files. > F: drivers/net/ all files in and below drivers/net > > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: " Dan Williams 2019-09-16 12:35 ` Jani Nikula @ 2019-10-01 13:55 ` Jonathan Corbet 2019-10-01 18:17 ` Martin K. Petersen 2019-11-07 20:13 ` Jonathan Corbet 1 sibling, 2 replies; 82+ messages in thread From: Jonathan Corbet @ 2019-10-01 13:55 UTC (permalink / raw) To: Dan Williams Cc: vishal.l.verma, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Dmitry Vyukov, Mauro Carvalho Chehab, Steve French, Tobin C. Harding On Wed, 11 Sep 2019 08:48:54 -0700 Dan Williams <dan.j.williams@intel.com> wrote: > As presented at the 2018 Linux Plumbers conference [1], the Maintainer > Entry Profile (formerly Subsystem Profile) is proposed as a way to reduce > friction between committers and maintainers and encourage conversations > amongst maintainers about common best practices. While coding-style, > submit-checklist, and submitting-drivers lay out some common expectations > there remain local customs and maintainer preferences that vary by > subsystem. > > The profile contains short answers to some of the common policy questions a > contributor might have that are local to the subsystem / device-driver, or > otherwise not covered by the top-level process documents. > > Overview: General introduction to how the subsystem operates > Submit Checklist Addendum: Mechanical items that gate submission staging > Key Cycle Dates: > - Last -rc for new feature submissions: Expected lead time for submissions > - Last -rc to merge features: Deadline for merge decisions > Coding Style Addendum: Clarifications of local style preferences > Resubmit Cadence: When to ping the maintainer > Checkpatch / Style Cleanups: Policy on pure cleanup patches So I'm finally back home after my European tour, and I have it on good authority that my bag might even get here eventually too. That means I'm digging through a pile of docs stuff I've been neglecting badly... My intention is to apply these patches. But as I was reading through them, one little nagging thing came to mind... > See Documentation/maintainer/maintainer-entry-profile.rst for more details, > and a follow-on example profile for the libnvdimm subsystem. Thus far, the maintainer guide is focused on how to *be* a maintainer. This document, instead, is more about how to deal with specific maintainers. So I suspect that Documentation/maintainer might be the wrong place for it. Should we maybe place it instead under Documentation/process, or even create a new top-level "book" for this information? Thanks, jon _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile 2019-10-01 13:55 ` Jonathan Corbet @ 2019-10-01 18:17 ` Martin K. Petersen 2019-11-07 20:13 ` Jonathan Corbet 1 sibling, 0 replies; 82+ messages in thread From: Martin K. Petersen @ 2019-10-01 18:17 UTC (permalink / raw) To: Jonathan Corbet Cc: vishal.l.verma, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Dmitry Vyukov, Mauro Carvalho Chehab, Steve French, Tobin C. Harding Jonathan, > Thus far, the maintainer guide is focused on how to *be* a maintainer. > This document, instead, is more about how to deal with specific > maintainers. So I suspect that Documentation/maintainer might be the > wrong place for it. > > Should we maybe place it instead under Documentation/process, or even > create a new top-level "book" for this information? I think Documentation/process is the right place for all the common practices and guidelines for code submission. Documentation is already pretty big. And based on the discussions in this thread, I think we're better off enhancing the existing process documents instead of introducing more places for people to look. -- Martin K. Petersen Oracle Linux Engineering _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile 2019-10-01 13:55 ` Jonathan Corbet 2019-10-01 18:17 ` Martin K. Petersen @ 2019-11-07 20:13 ` Jonathan Corbet 2019-11-08 2:41 ` Dan Williams 1 sibling, 1 reply; 82+ messages in thread From: Jonathan Corbet @ 2019-11-07 20:13 UTC (permalink / raw) To: Dan Williams Cc: vishal.l.verma, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Dmitry Vyukov, Mauro Carvalho Chehab, Steve French, Tobin C. Harding Hi, Dan, A month or so ago I wrote... > > See Documentation/maintainer/maintainer-entry-profile.rst for more details, > > and a follow-on example profile for the libnvdimm subsystem. > > Thus far, the maintainer guide is focused on how to *be* a maintainer. > This document, instead, is more about how to deal with specific > maintainers. So I suspect that Documentation/maintainer might be the > wrong place for it. > > Should we maybe place it instead under Documentation/process, or even > create a new top-level "book" for this information? Unless I missed it, I've not heard back from you on this. I'd like to get this stuff pulled in for 5.5 if possible... would you object if I were to apply your patches, then tack on a move over to the process guide? Thanks, jon _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile 2019-11-07 20:13 ` Jonathan Corbet @ 2019-11-08 2:41 ` Dan Williams 0 siblings, 0 replies; 82+ messages in thread From: Dan Williams @ 2019-11-08 2:41 UTC (permalink / raw) To: Jonathan Corbet Cc: Vishal L Verma, ksummit, linux-nvdimm, Greg Kroah-Hartman, Linux Kernel Mailing List, Dmitry Vyukov, Mauro Carvalho Chehab, Steve French, Tobin C. Harding On Thu, Nov 7, 2019 at 12:13 PM Jonathan Corbet <corbet@lwn.net> wrote: > > Hi, Dan, > > A month or so ago I wrote... > > > > See Documentation/maintainer/maintainer-entry-profile.rst for more details, > > > and a follow-on example profile for the libnvdimm subsystem. > > > > Thus far, the maintainer guide is focused on how to *be* a maintainer. > > This document, instead, is more about how to deal with specific > > maintainers. So I suspect that Documentation/maintainer might be the > > wrong place for it. > > > > Should we maybe place it instead under Documentation/process, or even > > create a new top-level "book" for this information? > > Unless I missed it, I've not heard back from you on this. I'd like to get > this stuff pulled in for 5.5 if possible... would you object if I were to > apply your patches, then tack on a move over to the process guide? Sorry for the delay. Yes, the process book is a better location now that this information is focused on being supplemental guidelines for submitters rather than a "how to maintain X subsystem" guide. I do want to respin this without the Coding Style addendum to address the specific feedback there, but other than that I'm happy to see this move forward. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-11 15:48 [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: " Dan Williams @ 2019-09-11 15:48 ` Dan Williams 2019-09-11 17:42 ` Vishal Verma ` (3 more replies) 2019-09-11 16:40 ` [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen 2019-09-12 13:10 ` Bart Van Assche 4 siblings, 4 replies; 82+ messages in thread From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw) To: linux-kernel; +Cc: Vishal Verma, Dave Jiang, ksummit-discuss, linux-nvdimm Document the basic policies of the libnvdimm subsystem and provide a first example of a Maintainer Entry Profile for others to duplicate and edit. Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- Documentation/nvdimm/maintainer-entry-profile.rst | 64 +++++++++++++++++++++ MAINTAINERS | 4 + 2 files changed, 68 insertions(+) create mode 100644 Documentation/nvdimm/maintainer-entry-profile.rst diff --git a/Documentation/nvdimm/maintainer-entry-profile.rst b/Documentation/nvdimm/maintainer-entry-profile.rst new file mode 100644 index 000000000000..c102950f2257 --- /dev/null +++ b/Documentation/nvdimm/maintainer-entry-profile.rst @@ -0,0 +1,64 @@ +LIBNVDIMM Maintainer Entry Profile +================================== + +Overview +-------- +The libnvdimm subsystem manages persistent memory across multiple +architectures. The mailing list, is tracked by patchwork here: +https://patchwork.kernel.org/project/linux-nvdimm/list/ +...and that instance is configured to give feedback to submitters on +patch acceptance and upstream merge. Patches are merged to either the +'libnvdimm-fixes', or 'libnvdimm-for-next' branch. Those branches are +available here: +https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/ + +In general patches can be submitted against the latest -rc, however if +the incoming code change is dependent on other pending changes then the +patch should be based on the libnvdimm-for-next branch. However, since +persistent memory sits at the intersection of storage and memory there +are cases where patches are more suitable to be merged through a +Filesystem or the Memory Management tree. When in doubt copy the nvdimm +list and the maintainers will help route. + +Submissions will be exposed to the kbuild robot for compile regression +testing. It helps to get a success notification from that infrastructure +before submitting, but it is not required. + + +Submit Checklist Addendum +------------------------- +There are unit tests for the subsystem via the ndctl utility: +https://github.com/pmem/ndctl +Those tests need to be passed before the patches go upstream, but not +necessarily before initial posting. Contact the list if you need help +getting the test environment set up. + + +Key Cycle Dates +--------------- +New submissions can be sent at any time, but if they intend to hit the +next merge window they should be sent before -rc4, and ideally +stabilized in the libnvdimm-for-next branch by -rc6. Of course if a +patch set requires more than 2 weeks of review -rc4 is already too late +and some patches may require multiple development cycles to review. + + +Coding Style Addendum +--------------------- +libnvdimm expects multi-line statements to be double indented. I.e. + + if (x... + && ...y) { + + +Review Cadence +-------------- +In general, please wait up to one week before pinging for feedback. A +private mail reminder is preferred. Alternatively ask for other +developers that have Reviewed-by tags for libnvdimm changes to take a +look and offer their opinion. + + +Style Cleanup Patches +--------------------- +Standalone style-cleanups are welcome. diff --git a/MAINTAINERS b/MAINTAINERS index e5d111a86e61..2be1e18a368e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9185,6 +9185,7 @@ M: Dan Williams <dan.j.williams@intel.com> M: Vishal Verma <vishal.l.verma@intel.com> M: Dave Jiang <dave.jiang@intel.com> L: linux-nvdimm@lists.01.org +P: Documentation/nvdimm/maintainer-entry-profile.rst Q: https://patchwork.kernel.org/project/linux-nvdimm/list/ S: Supported F: drivers/nvdimm/blk.c @@ -9195,6 +9196,7 @@ M: Vishal Verma <vishal.l.verma@intel.com> M: Dan Williams <dan.j.williams@intel.com> M: Dave Jiang <dave.jiang@intel.com> L: linux-nvdimm@lists.01.org +P: Documentation/nvdimm/maintainer-entry-profile.rst Q: https://patchwork.kernel.org/project/linux-nvdimm/list/ S: Supported F: drivers/nvdimm/btt* @@ -9204,6 +9206,7 @@ M: Dan Williams <dan.j.williams@intel.com> M: Vishal Verma <vishal.l.verma@intel.com> M: Dave Jiang <dave.jiang@intel.com> L: linux-nvdimm@lists.01.org +P: Documentation/nvdimm/maintainer-entry-profile.rst Q: https://patchwork.kernel.org/project/linux-nvdimm/list/ S: Supported F: drivers/nvdimm/pmem* @@ -9223,6 +9226,7 @@ M: Dave Jiang <dave.jiang@intel.com> M: Keith Busch <keith.busch@intel.com> M: Ira Weiny <ira.weiny@intel.com> L: linux-nvdimm@lists.01.org +P: Documentation/nvdimm/maintainer-entry-profile.rst Q: https://patchwork.kernel.org/project/linux-nvdimm/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git S: Supported _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams @ 2019-09-11 17:42 ` Vishal Verma 2019-09-11 18:43 ` Dan Carpenter ` (2 subsequent siblings) 3 siblings, 0 replies; 82+ messages in thread From: Vishal Verma @ 2019-09-11 17:42 UTC (permalink / raw) To: Dan Williams, linux-kernel; +Cc: Dave Jiang, ksummit-discuss, linux-nvdimm > Document the basic policies of the libnvdimm subsystem and provide a first > example of a Maintainer Entry Profile for others to duplicate and edit. > > Cc: Vishal Verma <vishal.l.verma@intel.com> > Cc: Dave Jiang <dave.jiang@intel.com> > Signed-off-by: Dan Williams <dan.j.williams@intel.com> > --- > Documentation/nvdimm/maintainer-entry-profile.rst | 64 +++++++++++++++++++++ > MAINTAINERS | 4 + > 2 files changed, 68 insertions(+) > create mode 100644 Documentation/nvdimm/maintainer-entry-profile.rst > Looks good to me, Acked-by: Vishal Verma <vishal.l.verma@intel.com> _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams 2019-09-11 17:42 ` Vishal Verma @ 2019-09-11 18:43 ` Dan Carpenter 2019-09-11 22:11 ` Jens Axboe 2019-09-11 20:30 ` Joe Perches 2019-09-13 16:19 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Mauro Carvalho Chehab 3 siblings, 1 reply; 82+ messages in thread From: Dan Carpenter @ 2019-09-11 18:43 UTC (permalink / raw) To: Dan Williams Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma, linux-kernel, bpf On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote: > +Coding Style Addendum > +--------------------- > +libnvdimm expects multi-line statements to be double indented. I.e. > + > + if (x... > + && ...y) { That looks horrible and it causes a checkpatch warning. :( Why not do it the same way that everyone else does it. if (blah_blah_x && <-- && has to be on the first line for checkpatch blah_blah_y) { <-- [tab][space][space][space][space]blah Now all the conditions are aligned visually which makes it readable. They aren't aligned with the indent block so it's easy to tell the inside from the if condition. I kind of hate all this extra documentation because now everyone thinks they can invent new hoops to jump through. Speaking of hoops, the BPF documentation says that you have to figure out which tree a patch applies to instead of just working against linux-next. Is there an automated way to do that? I looked through my inbox and there are a bunch of patches marked as going through the bpf-next tree but about half were marked incorrectly so it looks like everyone who tries to tag their patches is going to do it badly anyway. regards, dan carpenter _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-11 18:43 ` Dan Carpenter @ 2019-09-11 22:11 ` Jens Axboe 2019-09-12 7:41 ` Dan Williams ` (2 more replies) 0 siblings, 3 replies; 82+ messages in thread From: Jens Axboe @ 2019-09-11 22:11 UTC (permalink / raw) To: Dan Carpenter, Dan Williams Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma, linux-kernel, bpf On 9/11/19 12:43 PM, Dan Carpenter wrote: > On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote: >> +Coding Style Addendum >> +--------------------- >> +libnvdimm expects multi-line statements to be double indented. I.e. >> + >> + if (x... >> + && ...y) { > > That looks horrible and it causes a checkpatch warning. :( Why not > do it the same way that everyone else does it. > > if (blah_blah_x && <-- && has to be on the first line for checkpatch > blah_blah_y) { <-- [tab][space][space][space][space]blah > > Now all the conditions are aligned visually which makes it readable. > They aren't aligned with the indent block so it's easy to tell the > inside from the if condition. > > I kind of hate all this extra documentation because now everyone thinks > they can invent new hoops to jump through. FWIW, I completely agree with Dan (Carpenter) here. I absolutely dislike having these kinds of files, and with subsystems imposing weird restrictions on style (like the quoted example, yuck). Additionally, it would seem saner to standardize rules around when code is expected to hit the maintainers hands for kernel releases. Both yours and Martins deals with that, there really shouldn't be the need to have this specified in detail per sub-system. -- Jens Axboe _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-11 22:11 ` Jens Axboe @ 2019-09-12 7:41 ` Dan Williams [not found] ` <CANiq72k2so3ZcqA3iRziGY=Shd_B1=qGoXXROeAF7Y3+pDmqyA@mail.gmail.com> 2019-09-13 7:09 ` Jonathan Corbet 2019-09-13 21:44 ` Martin K. Petersen 2 siblings, 1 reply; 82+ messages in thread From: Dan Williams @ 2019-09-12 7:41 UTC (permalink / raw) To: Jens Axboe Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, Linux Kernel Mailing List, bpf, Dan Carpenter On Wed, Sep 11, 2019 at 3:11 PM Jens Axboe <axboe@kernel.dk> wrote: > > On 9/11/19 12:43 PM, Dan Carpenter wrote: > > On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote: > >> +Coding Style Addendum > >> +--------------------- > >> +libnvdimm expects multi-line statements to be double indented. I.e. > >> + > >> + if (x... > >> + && ...y) { > > > > That looks horrible and it causes a checkpatch warning. :( Why not > > do it the same way that everyone else does it. > > > > if (blah_blah_x && <-- && has to be on the first line for checkpatch > > blah_blah_y) { <-- [tab][space][space][space][space]blah > > > > Now all the conditions are aligned visually which makes it readable. > > They aren't aligned with the indent block so it's easy to tell the > > inside from the if condition. > > > > I kind of hate all this extra documentation because now everyone thinks > > they can invent new hoops to jump through. > > FWIW, I completely agree with Dan (Carpenter) here. I absolutely > dislike having these kinds of files, and with subsystems imposing weird > restrictions on style (like the quoted example, yuck). > > Additionally, it would seem saner to standardize rules around when > code is expected to hit the maintainers hands for kernel releases. Both > yours and Martins deals with that, there really shouldn't be the need > to have this specified in detail per sub-system. So this is *the* point of the exercise. I picked up this indentation habit a long while back in response to review feedback on a patch to a subsystem that formatted code this way. At the time CodingStyle did not contradict the maintainer's preference, so I adopted it across the board. Now I come to find that CodingStyle has settled on clang-format (in the last 15 months) as the new standard which is a much better answer to me than a manually specified style open to interpretation. I'll take a look at getting libnvdimm converted over. If we can take that further and standardize all of the places where contributors see variations across subsystems on the fundamental questions of style, timing, follow-up, and unit test invocation the Maintainer Entry Profile can be superseded with common guidelines. Otherwise, yes I completely agree with you that a "Maintainer Entry Profile" is a sad comment on the state of what contributors need to navigate, but that's today's reality that needs to be addressed. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
[parent not found: <CANiq72k2so3ZcqA3iRziGY=Shd_B1=qGoXXROeAF7Y3+pDmqyA@mail.gmail.com>]
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile [not found] ` <CANiq72k2so3ZcqA3iRziGY=Shd_B1=qGoXXROeAF7Y3+pDmqyA@mail.gmail.com> @ 2019-09-12 10:18 ` Joe Perches 0 siblings, 0 replies; 82+ messages in thread From: Joe Perches @ 2019-09-12 10:18 UTC (permalink / raw) To: Miguel Ojeda, Dan Williams Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, Linux Kernel Mailing List, bpf, Dan Carpenter On Thu, 2019-09-12 at 10:24 +0200, Miguel Ojeda wrote: > On Thu, Sep 12, 2019 at 9:43 AM Dan Williams <dan.j.williams@intel.com> wrote: > > Now I come to find that CodingStyle has settled on clang-format (in > > the last 15 months) as the new standard which is a much better answer > > to me than a manually specified style open to interpretation. I'll > > take a look at getting libnvdimm converted over. > > Note that clang-format cannot do everything as we want within the > kernel just yet, but it is a close enough approximation -- it is near > the point where we could simply agree to use it and stop worrying > about styling issues. However, that would mean everyone needs to have > a recent clang-format available, which I think is the biggest obstacle > at the moment. I don't think that's close to true yet for clang-format. For instance: clang-format does not do anything with missing braces, or coalescing multi-part strings, or any number of other nominal coding style defects like all the for_each macros, aligning or not aligning columnar contents appropriately, etc... clang-format as yet has no taste. I believe it'll take a lot of work to improve it to a point where its formatting is acceptable and appropriate. An AI rather than a table based system like clang-format is more likely to be a real solution, but training that AI isn't a thing that I want to do. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-11 22:11 ` Jens Axboe 2019-09-12 7:41 ` Dan Williams @ 2019-09-13 7:09 ` Jonathan Corbet 2019-09-13 11:48 ` Dan Carpenter 2019-09-13 21:44 ` Martin K. Petersen 2 siblings, 1 reply; 82+ messages in thread From: Jonathan Corbet @ 2019-09-13 7:09 UTC (permalink / raw) To: Jens Axboe Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma, linux-kernel, bpf, Dan Carpenter On Wed, 11 Sep 2019 16:11:29 -0600 Jens Axboe <axboe@kernel.dk> wrote: > On 9/11/19 12:43 PM, Dan Carpenter wrote: > > > > I kind of hate all this extra documentation because now everyone thinks > > they can invent new hoops to jump through. > > FWIW, I completely agree with Dan (Carpenter) here. I absolutely > dislike having these kinds of files, and with subsystems imposing weird > restrictions on style (like the quoted example, yuck). > > Additionally, it would seem saner to standardize rules around when > code is expected to hit the maintainers hands for kernel releases. Both > yours and Martins deals with that, there really shouldn't be the need > to have this specified in detail per sub-system. This sort of objection came up at the maintainers summit yesterday; the consensus was that, while we might not like subsystem-specific rules, they do currently exist and we're just documenting reality. To paraphrase Phillip K. Dick, reality is that which, when you refuse to document it, doesn't go away. So I'm expecting to take this kind of stuff into Documentation/. My own personal hope is that it can maybe serve to shame some of these "local quirks" out of existence. The evidence from this brief discussion suggests that this might indeed happen. Thanks, jon _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-13 7:09 ` Jonathan Corbet @ 2019-09-13 11:48 ` Dan Carpenter 2019-09-13 12:18 ` Dan Williams ` (3 more replies) 0 siblings, 4 replies; 82+ messages in thread From: Dan Carpenter @ 2019-09-13 11:48 UTC (permalink / raw) To: Jonathan Corbet Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma, linux-kernel, bpf On Fri, Sep 13, 2019 at 01:09:37AM -0600, Jonathan Corbet wrote: > On Wed, 11 Sep 2019 16:11:29 -0600 > Jens Axboe <axboe@kernel.dk> wrote: > > > On 9/11/19 12:43 PM, Dan Carpenter wrote: > > > > > > I kind of hate all this extra documentation because now everyone thinks > > > they can invent new hoops to jump through. > > > > FWIW, I completely agree with Dan (Carpenter) here. I absolutely > > dislike having these kinds of files, and with subsystems imposing weird > > restrictions on style (like the quoted example, yuck). > > > > Additionally, it would seem saner to standardize rules around when > > code is expected to hit the maintainers hands for kernel releases. Both > > yours and Martins deals with that, there really shouldn't be the need > > to have this specified in detail per sub-system. > > This sort of objection came up at the maintainers summit yesterday; the > consensus was that, while we might not like subsystem-specific rules, they > do currently exist and we're just documenting reality. To paraphrase > Phillip K. Dick, reality is that which, when you refuse to document it, > doesn't go away. There aren't that many subsystem rules. The big exception is networking, with the comment style and reverse Chrismas tree declarations. Also you have to label which git tree the patch applies to like [net] or [net-next]. It used to be that infiniband used "sizeof foo" instead of sizeof(foo) but now there is a new maintainer. There is one subsystem which where the maintainer will capitalize your patch prefix and complain. There are others where they will silently change it to lower case. (Maybe that has changed in recent years). There is one subsystem where the maintainer is super strict rules that you can't use "I" or "we" in the commit message. So you can't say "I noticed a bug while reviewing", you have to say "The code has a bug". Some maintainers have rules about what you can put in the declaration block. No kmalloc() in the declarations is a common rule. "struct foo *p = kmalloc();". Some people (I do) have strict rules for error handling, but most won't complain unless the error handling has bugs. The bpf people want you to put [bpf] or [bpf-next] in the subject. Everyone just guesses, and uneducated guesses are worse than leaving it blank, but that's just my opinion. > So I'm expecting to take this kind of stuff into Documentation/. My own > personal hope is that it can maybe serve to shame some of these "local > quirks" out of existence. The evidence from this brief discussion suggests > that this might indeed happen. I don't think it's shaming, I think it's validating. Everyone just insists that since it's written in the Book of Rules then it's our fault for not reading it. It's like those EULA things where there is more text than anyone can physically read in a life time. And the documentation doesn't help. For example, I knew people's rules about capitalizing the subject but I'd just forget. I say that if you can't be bothered to add it to checkpatch then it means you don't really care that strongly. regards, dan carpenter _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-13 11:48 ` Dan Carpenter @ 2019-09-13 12:18 ` Dan Williams 2019-09-13 15:00 ` Randy Dunlap ` (2 subsequent siblings) 3 siblings, 0 replies; 82+ messages in thread From: Dan Williams @ 2019-09-13 12:18 UTC (permalink / raw) To: Dan Carpenter Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, Linux Kernel Mailing List, bpf On Fri, Sep 13, 2019 at 4:49 AM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > On Fri, Sep 13, 2019 at 01:09:37AM -0600, Jonathan Corbet wrote: > > On Wed, 11 Sep 2019 16:11:29 -0600 > > Jens Axboe <axboe@kernel.dk> wrote: > > > > > On 9/11/19 12:43 PM, Dan Carpenter wrote: > > > > > > > > I kind of hate all this extra documentation because now everyone thinks > > > > they can invent new hoops to jump through. > > > > > > FWIW, I completely agree with Dan (Carpenter) here. I absolutely > > > dislike having these kinds of files, and with subsystems imposing weird > > > restrictions on style (like the quoted example, yuck). > > > > > > Additionally, it would seem saner to standardize rules around when > > > code is expected to hit the maintainers hands for kernel releases. Both > > > yours and Martins deals with that, there really shouldn't be the need > > > to have this specified in detail per sub-system. > > > > This sort of objection came up at the maintainers summit yesterday; the > > consensus was that, while we might not like subsystem-specific rules, they > > do currently exist and we're just documenting reality. To paraphrase > > Phillip K. Dick, reality is that which, when you refuse to document it, > > doesn't go away. > > There aren't that many subsystem rules. The big exception is > networking, with the comment style and reverse Chrismas tree > declarations. Also you have to label which git tree the patch applies > to like [net] or [net-next]. > > It used to be that infiniband used "sizeof foo" instead of sizeof(foo) > but now there is a new maintainer. > > There is one subsystem which where the maintainer will capitalize your > patch prefix and complain. There are others where they will silently > change it to lower case. (Maybe that has changed in recent years). > > There is one subsystem where the maintainer is super strict rules that > you can't use "I" or "we" in the commit message. So you can't say "I > noticed a bug while reviewing", you have to say "The code has a bug". > > Some maintainers have rules about what you can put in the declaration > block. No kmalloc() in the declarations is a common rule. > "struct foo *p = kmalloc();". > > Some people (I do) have strict rules for error handling, but most won't > complain unless the error handling has bugs. > > The bpf people want you to put [bpf] or [bpf-next] in the subject. > Everyone just guesses, and uneducated guesses are worse than leaving it > blank, but that's just my opinion. > > > So I'm expecting to take this kind of stuff into Documentation/. My own > > personal hope is that it can maybe serve to shame some of these "local > > quirks" out of existence. The evidence from this brief discussion suggests > > that this might indeed happen. > > I don't think it's shaming, I think it's validating. Everyone just > insists that since it's written in the Book of Rules then it's our fault > for not reading it. It's like those EULA things where there is more > text than anyone can physically read in a life time. > > And the documentation doesn't help. For example, I knew people's rules > about capitalizing the subject but I'd just forget. I say that if you > can't be bothered to add it to checkpatch then it means you don't really > care that strongly. True, can someone with better perl skills than me take a shot at a rule for checkpatch to catch the capitalization preference based on the subsystem being touched, or otherwise agree that if a maintainer has a changelog capitalization preference they just silently fix it up at application time and not waste time pointing out something so trivial? For example, I notice Linus likes "-" instead of "*" for bullet lists in changelogs he just fixes it up silently if I forget. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-13 11:48 ` Dan Carpenter 2019-09-13 12:18 ` Dan Williams @ 2019-09-13 15:00 ` Randy Dunlap 2019-09-13 15:46 ` Rob Herring 2019-09-13 17:57 ` Geert Uytterhoeven 2019-09-16 12:42 ` Jani Nikula [not found] ` <20190917161608.GA12866@ziepe.ca> 3 siblings, 2 replies; 82+ messages in thread From: Randy Dunlap @ 2019-09-13 15:00 UTC (permalink / raw) To: Dan Carpenter, Jonathan Corbet Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma, linux-kernel, bpf On 9/13/19 4:48 AM, Dan Carpenter wrote: >> So I'm expecting to take this kind of stuff into Documentation/. My own >> personal hope is that it can maybe serve to shame some of these "local >> quirks" out of existence. The evidence from this brief discussion suggests >> that this might indeed happen. > > I don't think it's shaming, I think it's validating. Everyone just > insists that since it's written in the Book of Rules then it's our fault > for not reading it. It's like those EULA things where there is more > text than anyone can physically read in a life time. Yes, agreed. > And the documentation doesn't help. For example, I knew people's rules > about capitalizing the subject but I'd just forget. I say that if you > can't be bothered to add it to checkpatch then it means you don't really > care that strongly. If a subsystem requires a certain spelling/capitalization in patch email subjects, it should be added to MAINTAINERS IMO. E.g., E: NuBus -- ~Randy _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-13 15:00 ` Randy Dunlap @ 2019-09-13 15:46 ` Rob Herring 2019-09-13 16:42 ` Joe Perches 2019-09-13 17:57 ` Geert Uytterhoeven 1 sibling, 1 reply; 82+ messages in thread From: Rob Herring @ 2019-09-13 15:46 UTC (permalink / raw) To: Randy Dunlap Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, linux-kernel, bpf, Dan Carpenter On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap <rdunlap@infradead.org> wrote: > > On 9/13/19 4:48 AM, Dan Carpenter wrote: > > >> So I'm expecting to take this kind of stuff into Documentation/. My own > >> personal hope is that it can maybe serve to shame some of these "local > >> quirks" out of existence. The evidence from this brief discussion suggests > >> that this might indeed happen. > > > > I don't think it's shaming, I think it's validating. Everyone just > > insists that since it's written in the Book of Rules then it's our fault > > for not reading it. It's like those EULA things where there is more > > text than anyone can physically read in a life time. > > Yes, agreed. > > > And the documentation doesn't help. For example, I knew people's rules > > about capitalizing the subject but I'd just forget. I say that if you > > can't be bothered to add it to checkpatch then it means you don't really > > care that strongly. > > If a subsystem requires a certain spelling/capitalization in patch email > subjects, it should be added to MAINTAINERS IMO. E.g., > E: NuBus +1 Better make this a regex to deal with (net|net-next). We could probably script populating MAINTAINERS with this using how it is done manually: git log --oneline <dir> Rob _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-13 15:46 ` Rob Herring @ 2019-09-13 16:42 ` Joe Perches 2019-09-13 19:32 ` Rob Herring 0 siblings, 1 reply; 82+ messages in thread From: Joe Perches @ 2019-09-13 16:42 UTC (permalink / raw) To: Rob Herring, Randy Dunlap Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, linux-kernel, bpf, Dan Carpenter On Fri, 2019-09-13 at 16:46 +0100, Rob Herring wrote: > On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap <rdunlap@infradead.org> wrote: > > On 9/13/19 4:48 AM, Dan Carpenter wrote: > > > > > > So I'm expecting to take this kind of stuff into Documentation/. My own > > > > personal hope is that it can maybe serve to shame some of these "local > > > > quirks" out of existence. The evidence from this brief discussion suggests > > > > that this might indeed happen. > > > > > > I don't think it's shaming, I think it's validating. Everyone just > > > insists that since it's written in the Book of Rules then it's our fault > > > for not reading it. It's like those EULA things where there is more > > > text than anyone can physically read in a life time. > > > > Yes, agreed. > > > > > And the documentation doesn't help. For example, I knew people's rules > > > about capitalizing the subject but I'd just forget. I say that if you > > > can't be bothered to add it to checkpatch then it means you don't really > > > care that strongly. > > > > If a subsystem requires a certain spelling/capitalization in patch email > > subjects, it should be added to MAINTAINERS IMO. E.g., > > E: NuBus > > +1 > > Better make this a regex to deal with (net|net-next). > > We could probably script populating MAINTAINERS with this using how it > is done manually: git log --oneline <dir> I made a similar proposal nearly a decade ago to add a grammar to MAINTAINERS sections for patch subject prefixes. https://lore.kernel.org/lkml/1289919077.28741.50.camel@Joe-Laptop/ _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-13 16:42 ` Joe Perches @ 2019-09-13 19:32 ` Rob Herring 0 siblings, 0 replies; 82+ messages in thread From: Rob Herring @ 2019-09-13 19:32 UTC (permalink / raw) To: Joe Perches Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, linux-kernel, bpf, Dan Carpenter On Fri, Sep 13, 2019 at 11:42 AM Joe Perches <joe@perches.com> wrote: > > On Fri, 2019-09-13 at 16:46 +0100, Rob Herring wrote: > > On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap <rdunlap@infradead.org> wrote: > > > On 9/13/19 4:48 AM, Dan Carpenter wrote: > > > > > > > > So I'm expecting to take this kind of stuff into Documentation/. My own > > > > > personal hope is that it can maybe serve to shame some of these "local > > > > > quirks" out of existence. The evidence from this brief discussion suggests > > > > > that this might indeed happen. > > > > > > > > I don't think it's shaming, I think it's validating. Everyone just > > > > insists that since it's written in the Book of Rules then it's our fault > > > > for not reading it. It's like those EULA things where there is more > > > > text than anyone can physically read in a life time. > > > > > > Yes, agreed. > > > > > > > And the documentation doesn't help. For example, I knew people's rules > > > > about capitalizing the subject but I'd just forget. I say that if you > > > > can't be bothered to add it to checkpatch then it means you don't really > > > > care that strongly. > > > > > > If a subsystem requires a certain spelling/capitalization in patch email > > > subjects, it should be added to MAINTAINERS IMO. E.g., > > > E: NuBus > > > > +1 > > > > Better make this a regex to deal with (net|net-next). > > > > We could probably script populating MAINTAINERS with this using how it > > is done manually: git log --oneline <dir> > > I made a similar proposal nearly a decade ago to add a grammar > to MAINTAINERS sections for patch subject prefixes. > > https://lore.kernel.org/lkml/1289919077.28741.50.camel@Joe-Laptop/ Perhaps there's more support for it now. I didn't get through all the thread, but the positions seemed to range from "who cares, subjects are easy to edit" to "seems like a good idea and doesn't hurt". I probably would have implemented something, but perl (tacking on to checkpatch and having you tell me everything wrong is about all I can do :)). Rob _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-13 15:00 ` Randy Dunlap 2019-09-13 15:46 ` Rob Herring @ 2019-09-13 17:57 ` Geert Uytterhoeven 1 sibling, 0 replies; 82+ messages in thread From: Geert Uytterhoeven @ 2019-09-13 17:57 UTC (permalink / raw) To: Randy Dunlap Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, Linux Kernel Mailing List, bpf, Dan Carpenter Hi Randy, On Fri, Sep 13, 2019 at 5:00 PM Randy Dunlap <rdunlap@infradead.org> wrote: > On 9/13/19 4:48 AM, Dan Carpenter wrote: > >> So I'm expecting to take this kind of stuff into Documentation/. My own > >> personal hope is that it can maybe serve to shame some of these "local > >> quirks" out of existence. The evidence from this brief discussion suggests > >> that this might indeed happen. > > > > I don't think it's shaming, I think it's validating. Everyone just > > insists that since it's written in the Book of Rules then it's our fault > > for not reading it. It's like those EULA things where there is more > > text than anyone can physically read in a life time. > > Yes, agreed. > > > And the documentation doesn't help. For example, I knew people's rules > > about capitalizing the subject but I'd just forget. I say that if you > > can't be bothered to add it to checkpatch then it means you don't really > > care that strongly. > > If a subsystem requires a certain spelling/capitalization in patch email > subjects, it should be added to MAINTAINERS IMO. E.g., > E: NuBus Oh, I understood the question differently. I thought it was about "sub: system: Fix foo" vs. "sub: system: fix foo". For simple and trivial things, I tend to make changes while applying, as that's usually less work than complaining, and verifying that it's been fixed in the next (if any) version n days/weeks/months later. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-13 11:48 ` Dan Carpenter 2019-09-13 12:18 ` Dan Williams 2019-09-13 15:00 ` Randy Dunlap @ 2019-09-16 12:42 ` Jani Nikula [not found] ` <20190917161608.GA12866@ziepe.ca> 3 siblings, 0 replies; 82+ messages in thread From: Jani Nikula @ 2019-09-16 12:42 UTC (permalink / raw) To: Dan Carpenter, Jonathan Corbet Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma, linux-kernel, bpf On Fri, 13 Sep 2019, Dan Carpenter <dan.carpenter@oracle.com> wrote: > And the documentation doesn't help. For example, I knew people's rules > about capitalizing the subject but I'd just forget. I say that if you > can't be bothered to add it to checkpatch then it means you don't really > care that strongly. It would be entirely possible to add the subsystem/driver specific checkpatch rules to MAINTAINERS entries or directory specific config files. As checkpatch options directly. For example --strict --max-line-length=100 --ignore=BIT_MACRO,SPLIT_STRING,LONG_LINE_STRING,BOOL_MEMBER or whatever. SMOP. ;) BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
[parent not found: <20190917161608.GA12866@ziepe.ca>]
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile [not found] ` <20190917161608.GA12866@ziepe.ca> @ 2019-09-17 21:59 ` Dan Williams 0 siblings, 0 replies; 82+ messages in thread From: Dan Williams @ 2019-09-17 21:59 UTC (permalink / raw) To: Jason Gunthorpe Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, Linux Kernel Mailing List, bpf, Dan Carpenter On Tue, Sep 17, 2019 at 9:16 AM Jason Gunthorpe <jgg@ziepe.ca> wrote: > > On Fri, Sep 13, 2019 at 02:48:50PM +0300, Dan Carpenter wrote: > > > It used to be that infiniband used "sizeof foo" instead of sizeof(foo) > > but now there is a new maintainer. > > These days I run everything through checkpatch and generally don't > want to see much deviation from the 'normal' style, a few minor > clang-format quibbles and other check patch positives excluded. > > This means when people touch lines they have to adjust minor things > like the odd 'sizeof foo' to make it conforming. > > Like others there is a big historical mismatch and the best I hope for > is that new stuff follow the cannonical style. Trying to guess what > some appropriate mongral style is for each patch is just a waste of my > time. > > I also hold drivers/infiniband as an example of why the column > alignment style is harmful. That has not aged well and is the cause of > a lot of ugly things. > > > There is one subsystem where the maintainer is super strict rules that > > you can't use "I" or "we" in the commit message. So you can't say "I > > noticed a bug while reviewing", you have to say "The code has a bug". > > Ah, the imperative mood nitpick. This one is very exciting to explain > to non-native speakers. With many regular submitters I'm still at the > "I wish you would use proper grammer and sentence structure" phase.. > > These days I just end up copy editing most of the commit messages :( > > > I don't think it's shaming, I think it's validating. Everyone just > > insists that since it's written in the Book of Rules then it's our fault > > for not reading it. It's like those EULA things where there is more > > text than anyone can physically read in a life time. > > Yeah, I tend to agree. > > The big special cases with high patch volumes (net being the classic > example) should remain special. > > But everyone else is not special, and shouldn't act the same. > > The work people like DanC do with static analysis is valuable, and we > should not be insisting that those contributors have to jump through a > thousand special hoops. > > I have simply viewed it as the job of the maintainer to run the > process and deal with minor nit picks on the fly. > > Maybe that is what we should be documenting? In theory, yes, in practice, as long as there is an exception to the rule, it comes down to a question of "is this case special like net or not?". I'd rather not waste time debating that on a per-subsystem basis vs just getting it all documented for contributors. I do think it is worth clarifying in the guidelines of writing a profile to make an effort to not be special, and that odd looking rules will be questioned (like libnvdimm statement continuation), but lets not fight the new standards fight until it becomes apparent where the outliers lie. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-11 22:11 ` Jens Axboe 2019-09-12 7:41 ` Dan Williams 2019-09-13 7:09 ` Jonathan Corbet @ 2019-09-13 21:44 ` Martin K. Petersen 2019-09-16 7:01 ` Dan Carpenter 2 siblings, 1 reply; 82+ messages in thread From: Martin K. Petersen @ 2019-09-13 21:44 UTC (permalink / raw) To: Jens Axboe Cc: ksummit-discuss, linux-nvdimm, linux-kernel, bpf, Dan Carpenter Jens, > Additionally, it would seem saner to standardize rules around when > code is expected to hit the maintainers hands for kernel > releases. Both yours and Martins deals with that, there really > shouldn't be the need to have this specified in detail per sub-system. Yeah. There is basically nothing specific about SCSI in my write-up outside of the branch naming. I deliberately didn't mention coding style preferences. We have so much 20+ year old cruft in SCSI that's impossible to even entertain. But I do request new code to follow coding-style.rst. BYOXT. Also note that the original target audience for my document. It was aimed at onboarding new driver contributors from hardware companies. So people that don't live and breathe Linux development and who are not intimately familiar with the kernel development process. It's possible that we have this information in Documentation/ these days; I'll go look. But it didn't exist when this doc was written. And in my experience nobody coming to Linux development from the outside understands what the "merge window" is. And when the appropriate time is to submit patches and features. I think this would be a great area to have a common set of guidelines and documentation. I'd prefer for this to be global and then let maintainers apply their own wiggle room instead of documenting particular rules for a given subsystem. One pet peeve I have is that people are pretty bad at indicating the intended target tree. I often ask for it in private mail but the practice doesn't seem to stick. I spend a ton of time guessing whether a patch is a fix for a new feature in the x+1 queue or a fix for the current release. It is not always obvious. -- Martin K. Petersen Oracle Linux Engineering _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-13 21:44 ` Martin K. Petersen @ 2019-09-16 7:01 ` Dan Carpenter 2019-09-16 17:08 ` Martin K. Petersen 0 siblings, 1 reply; 82+ messages in thread From: Dan Carpenter @ 2019-09-16 7:01 UTC (permalink / raw) To: Martin K. Petersen; +Cc: bpf, linux-kernel, ksummit-discuss, linux-nvdimm On Fri, Sep 13, 2019 at 05:44:39PM -0400, Martin K. Petersen wrote: > One pet peeve I have is that people are pretty bad at indicating the > intended target tree. I often ask for it in private mail but the > practice doesn't seem to stick. I spend a ton of time guessing whether a > patch is a fix for a new feature in the x+1 queue or a fix for the > current release. It is not always obvious. The Fixes tag doesn't help? Of course, you've never asked me or anyone on kernel-newbies that question. We don't normally know the answer either. I do always try to figure it out for networking, but it's kind of a pain in the butt and I mess up surpisingly often for how much effort I put into getting it right. regards, dan carpenter _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-16 7:01 ` Dan Carpenter @ 2019-09-16 17:08 ` Martin K. Petersen 2019-09-16 17:15 ` Mark Brown 0 siblings, 1 reply; 82+ messages in thread From: Martin K. Petersen @ 2019-09-16 17:08 UTC (permalink / raw) To: Dan Carpenter; +Cc: ksummit-discuss, linux-nvdimm, linux-kernel, bpf Dan, >> One pet peeve I have is that people are pretty bad at indicating the >> intended target tree. I often ask for it in private mail but the >> practice doesn't seem to stick. I spend a ton of time guessing whether a >> patch is a fix for a new feature in the x+1 queue or a fix for the >> current release. It is not always obvious. > > The Fixes tag doesn't help? Always. > Of course, you've never asked me or anyone on kernel-newbies that > question. We don't normally know the answer either. I do always try > to figure it out for networking, but it's kind of a pain in the butt > and I mess up surpisingly often for how much effort I put into getting > it right. It's not a big issue for your patches. These are inevitably fixes and I'll pick an appropriate tree depending on where we are in the cycle, how likely one is to hit the issue, whether the driver is widely used, etc. Vendor driver submissions, however, are generally huge. Sometimes 50+ patches per submission window. And during this window I often get on the order of 10 to 20 patches for the same driver in the fixes tree. It is not always easy to determine whether a bug fix series is for one tree or the other. -- Martin K. Petersen Oracle Linux Engineering _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-16 17:08 ` Martin K. Petersen @ 2019-09-16 17:15 ` Mark Brown 0 siblings, 0 replies; 82+ messages in thread From: Mark Brown @ 2019-09-16 17:15 UTC (permalink / raw) To: Martin K. Petersen Cc: linux-kernel, bpf, ksummit-discuss, Dan Carpenter, linux-nvdimm [-- Attachment #1.1: Type: text/plain, Size: 801 bytes --] On Mon, Sep 16, 2019 at 01:08:45PM -0400, Martin K. Petersen wrote: > Vendor driver submissions, however, are generally huge. Sometimes 50+ > patches per submission window. And during this window I often get on the > order of 10 to 20 patches for the same driver in the fixes tree. It is > not always easy to determine whether a bug fix series is for one tree or > the other. I get the impression that a lot of vendors just don't distinguish and only really care about getting things upstream, especially in the embedded world many of them realistically expect to be shipping a pile of out of tree patches to anyone using anything other than mainline anyway so it's not super clear to them that it's worthwhile. This goes back to the converstations about stable and how vendors interact with that. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 186 bytes --] _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams 2019-09-11 17:42 ` Vishal Verma 2019-09-11 18:43 ` Dan Carpenter @ 2019-09-11 20:30 ` Joe Perches 2019-09-13 16:19 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Mauro Carvalho Chehab 3 siblings, 0 replies; 82+ messages in thread From: Joe Perches @ 2019-09-11 20:30 UTC (permalink / raw) To: Dan Williams, linux-kernel Cc: Vishal Verma, Dave Jiang, ksummit-discuss, linux-nvdimm On Wed, 2019-09-11 at 08:48 -0700, Dan Williams wrote: > Document the basic policies of the libnvdimm subsystem and provide a first > example of a Maintainer Entry Profile for others to duplicate and edit. [] > +Coding Style Addendum > +--------------------- > +libnvdimm expects multi-line statements to be double indented. I.e. > + > + if (x... > + && ...y) { I don't find a good reason to do this. > diff --git a/MAINTAINERS b/MAINTAINERS [] > @@ -9185,6 +9185,7 @@ M: Dan Williams <dan.j.williams@intel.com> > M: Vishal Verma <vishal.l.verma@intel.com> > M: Dave Jiang <dave.jiang@intel.com> > L: linux-nvdimm@lists.01.org > +P: Documentation/nvdimm/maintainer-entry-profile.rst I also think the indirection to a separate file is not a good thing. Separate styles for individual subsystems is not something I would want to encourage. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams ` (2 preceding siblings ...) 2019-09-11 20:30 ` Joe Perches @ 2019-09-13 16:19 ` Mauro Carvalho Chehab 2019-09-13 16:19 ` Mauro Carvalho Chehab ` (2 more replies) 3 siblings, 3 replies; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-13 16:19 UTC (permalink / raw) To: Linux Media Mailing List; +Cc: Mauro Carvalho Chehab, ksummit-discuss Document the basic policies of the media subsystem profile. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> --- That's basically a modified version of: https://patchwork.linuxtv.org/patch/52999/ Applied to the new template Documentation/media/index.rst | 1 + .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++ MAINTAINERS | 1 + 3 files changed, 142 insertions(+) create mode 100644 Documentation/media/maintainer-entry-profile.rst diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst index 0301c25ff887..ac94685b822a 100644 --- a/Documentation/media/index.rst +++ b/Documentation/media/index.rst @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation .. toctree:: :maxdepth: 2 + maintainer-entry-profile media_uapi media_kapi dvb-drivers/index diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst new file mode 100644 index 000000000000..81d3b0f9c36a --- /dev/null +++ b/Documentation/media/maintainer-entry-profile.rst @@ -0,0 +1,140 @@ +Media Subsystem Profile +======================= + +Overview +-------- + +The media subsystem cover support for a variety of devices: stream +capture, analog and digital TV, cameras, remote controllers, HDMI CEC +and media pipeline control. + +It covers, mainly, the contents of those directories: + + - drivers/media + - drivers/staging/media + - Documentation/media + - include/media + +Both media userspace and Kernel APIs are documented and should be kept in +sync with the API changes. It means that all patches that add new +features to the subsystem should also bring changes to the corresponding +API files. + +Also, patches for device drivers that changes the Open Firmware/Device +Tree bindings should be reviewed by the Device Tree maintainers. + +Due to the size and wide scope of the media subsystem, media's +maintainership model is to have sub-maintainers that have a broad +knowledge of an specific aspect of the subsystem. It is a +sub-maintainers task to review the patches, providing feedback to users +if the patches are following the subsystem rules and are properly using +the media internal and external APIs. + +Patches for the media subsystem should be sent to the media mailing list +at linux-media@vger.kernel.org as plain text only e-mail. Emails with +HTML will be automatically rejected by the mail server. There's no need +to copy the maintainer or sub-maintainer(s). + +Media's workflow is heavily based on Patchwork, meaning that, once a patch +is submitted, it should appear at: + + - https://patchwork.linuxtv.org/project/linux-media/list/ + +If it doesn't automatically appear there after a few minutes, then +probably something got wrong on your submission. Please check if the +email is in plain text only and if your emailer is not mangling with +whitespaces before complaining or submit it again. + +Sub-maintainers ++++++++++++++++ + +At the media subsystem, we have a group of senior developers that are +responsible for doing the code reviews at the drivers (called +sub-maintainers), and another senior developer responsible for the +subsystem as a hole. For core changes, whenever possible, multiple +media (sub-)maintainers do the review. + +The sub-maintainers work on specific areas of the subsystem, as +described below: + +Digital TV: + Sean Young <sean@mess.org> + +HDMI CEC: + Hans Verkuil <hverkuil@xs4all.nl> + +Media controller drivers: + Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +Remote Controllers: + Sean Young <sean@mess.org> + +Sensor drivers: + Sakari Ailus <sakari.ailus@linux.intel.com> + +V4L2 drivers: + Hans Verkuil <hverkuil@xs4all.nl> + +Submit Checklist Addendum +------------------------- + +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ +that should be used in order to check if the drivers are properly +implementing the media APIs. + +Those tests need to be passed before the patches go upstream. + +Also, please notice that we build the Kernel with:: + + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script + +Where the check script is:: + + #!/bin/bash + /devel/smatch/smatch -p=kernel $@ >&2 + /devel/sparse/sparse $@ >&2 + +Be sure to not introduce new warnings on your patches. + +Key Cycle Dates +--------------- + +New submissions can be sent at any time, but if they intend to hit the +next merge window they should be sent before -rc5, and ideally stabilized +in the linux-media branch by -rc6. + +Coding Style Addendum +--------------------- + +Media development uses checkpatch on strict mode to verify the code style, e. g.:: + + $ ./script/checkpatch.pl --strict + +Review Cadence +-------------- + +Provided that your patch is at https://patchwork.linuxtv.org, it should +be sooner or later handled, so you don't need to re-submit a patch. + +Except for bug fixes, we don't usually add new patches to the development +tree between -rc6 and the next -rc1. + +Please notice that the media subsystem is a high traffic one, so it +could take a while for us to be able to review your patches. Feel free +to ping if you don't get a feedback on a couple of weeks or to ask +other developers to publicly add Reviewed-by and, more importantly, +Tested-by tags. + +Please notice that we expect a detailed description for Tested-by, +identifying what boards were used at the test and what it was tested. + +Style Cleanup Patches +--------------------- + +Style-cleanups are welcome when they come together with other changes +at the files where the style changes will affect. + +We may accept pure standalone style-cleanups, but they should be grouped +per directory. So, for example, if you're doing a cleanup at drivers +under drivers/media, please send a single patch for all drivers under +drivers/media/pci, another one for drivers/media/usb and so on. diff --git a/MAINTAINERS b/MAINTAINERS index 7c62b45201d7..e7f44ec05a42 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10077,6 +10077,7 @@ W: https://linuxtv.org Q: http://patchwork.kernel.org/project/linux-media/list/ T: git git://linuxtv.org/media_tree.git S: Maintained +P: Documentation/media/maintainer-entry-profile.rst F: Documentation/devicetree/bindings/media/ F: Documentation/media/ F: drivers/media/ -- 2.21.0 _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply related [flat|nested] 82+ messages in thread
* [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-13 16:19 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Mauro Carvalho Chehab @ 2019-09-13 16:19 ` Mauro Carvalho Chehab 2019-09-17 3:35 ` [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) Kees Cook 2019-09-18 12:36 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Laurent Pinchart 2 siblings, 0 replies; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-13 16:19 UTC (permalink / raw) To: Linux Media Mailing List; +Cc: Mauro Carvalho Chehab, ksummit-discuss Document the basic policies of the media subsystem profile. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> --- That's basically a modified version of: https://patchwork.linuxtv.org/patch/52999/ Applied to the new template Documentation/media/index.rst | 1 + .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++ MAINTAINERS | 1 + 3 files changed, 142 insertions(+) create mode 100644 Documentation/media/maintainer-entry-profile.rst diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst index 0301c25ff887..ac94685b822a 100644 --- a/Documentation/media/index.rst +++ b/Documentation/media/index.rst @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation .. toctree:: :maxdepth: 2 + maintainer-entry-profile media_uapi media_kapi dvb-drivers/index diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst new file mode 100644 index 000000000000..81d3b0f9c36a --- /dev/null +++ b/Documentation/media/maintainer-entry-profile.rst @@ -0,0 +1,140 @@ +Media Subsystem Profile +======================= + +Overview +-------- + +The media subsystem cover support for a variety of devices: stream +capture, analog and digital TV, cameras, remote controllers, HDMI CEC +and media pipeline control. + +It covers, mainly, the contents of those directories: + + - drivers/media + - drivers/staging/media + - Documentation/media + - include/media + +Both media userspace and Kernel APIs are documented and should be kept in +sync with the API changes. It means that all patches that add new +features to the subsystem should also bring changes to the corresponding +API files. + +Also, patches for device drivers that changes the Open Firmware/Device +Tree bindings should be reviewed by the Device Tree maintainers. + +Due to the size and wide scope of the media subsystem, media's +maintainership model is to have sub-maintainers that have a broad +knowledge of an specific aspect of the subsystem. It is a +sub-maintainers task to review the patches, providing feedback to users +if the patches are following the subsystem rules and are properly using +the media internal and external APIs. + +Patches for the media subsystem should be sent to the media mailing list +at linux-media@vger.kernel.org as plain text only e-mail. Emails with +HTML will be automatically rejected by the mail server. There's no need +to copy the maintainer or sub-maintainer(s). + +Media's workflow is heavily based on Patchwork, meaning that, once a patch +is submitted, it should appear at: + + - https://patchwork.linuxtv.org/project/linux-media/list/ + +If it doesn't automatically appear there after a few minutes, then +probably something got wrong on your submission. Please check if the +email is in plain text only and if your emailer is not mangling with +whitespaces before complaining or submit it again. + +Sub-maintainers ++++++++++++++++ + +At the media subsystem, we have a group of senior developers that are +responsible for doing the code reviews at the drivers (called +sub-maintainers), and another senior developer responsible for the +subsystem as a hole. For core changes, whenever possible, multiple +media (sub-)maintainers do the review. + +The sub-maintainers work on specific areas of the subsystem, as +described below: + +Digital TV: + Sean Young <sean@mess.org> + +HDMI CEC: + Hans Verkuil <hverkuil@xs4all.nl> + +Media controller drivers: + Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +Remote Controllers: + Sean Young <sean@mess.org> + +Sensor drivers: + Sakari Ailus <sakari.ailus@linux.intel.com> + +V4L2 drivers: + Hans Verkuil <hverkuil@xs4all.nl> + +Submit Checklist Addendum +------------------------- + +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ +that should be used in order to check if the drivers are properly +implementing the media APIs. + +Those tests need to be passed before the patches go upstream. + +Also, please notice that we build the Kernel with:: + + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script + +Where the check script is:: + + #!/bin/bash + /devel/smatch/smatch -p=kernel $@ >&2 + /devel/sparse/sparse $@ >&2 + +Be sure to not introduce new warnings on your patches. + +Key Cycle Dates +--------------- + +New submissions can be sent at any time, but if they intend to hit the +next merge window they should be sent before -rc5, and ideally stabilized +in the linux-media branch by -rc6. + +Coding Style Addendum +--------------------- + +Media development uses checkpatch on strict mode to verify the code style, e. g.:: + + $ ./script/checkpatch.pl --strict + +Review Cadence +-------------- + +Provided that your patch is at https://patchwork.linuxtv.org, it should +be sooner or later handled, so you don't need to re-submit a patch. + +Except for bug fixes, we don't usually add new patches to the development +tree between -rc6 and the next -rc1. + +Please notice that the media subsystem is a high traffic one, so it +could take a while for us to be able to review your patches. Feel free +to ping if you don't get a feedback on a couple of weeks or to ask +other developers to publicly add Reviewed-by and, more importantly, +Tested-by tags. + +Please notice that we expect a detailed description for Tested-by, +identifying what boards were used at the test and what it was tested. + +Style Cleanup Patches +--------------------- + +Style-cleanups are welcome when they come together with other changes +at the files where the style changes will affect. + +We may accept pure standalone style-cleanups, but they should be grouped +per directory. So, for example, if you're doing a cleanup at drivers +under drivers/media, please send a single patch for all drivers under +drivers/media/pci, another one for drivers/media/usb and so on. diff --git a/MAINTAINERS b/MAINTAINERS index 7c62b45201d7..e7f44ec05a42 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10077,6 +10077,7 @@ W: https://linuxtv.org Q: http://patchwork.kernel.org/project/linux-media/list/ T: git git://linuxtv.org/media_tree.git S: Maintained +P: Documentation/media/maintainer-entry-profile.rst F: Documentation/devicetree/bindings/media/ F: Documentation/media/ F: drivers/media/ -- 2.21.0 _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply related [flat|nested] 82+ messages in thread
* [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) 2019-09-13 16:19 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Mauro Carvalho Chehab 2019-09-13 16:19 ` Mauro Carvalho Chehab @ 2019-09-17 3:35 ` Kees Cook 2019-09-17 13:28 ` Mauro Carvalho Chehab 2019-09-18 12:36 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Laurent Pinchart 2 siblings, 1 reply; 82+ messages in thread From: Kees Cook @ 2019-09-17 3:35 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote: > Document the basic policies of the media subsystem profile. > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> > --- > > That's basically a modified version of: > https://patchwork.linuxtv.org/patch/52999/ > > Applied to the new template > > Documentation/media/index.rst | 1 + > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++ One idea I proposed to Dan at the Maintainer's Summit was to collect all the profiles is a single directory in Documentation/, since there are two ways someone would want to read profiles: 1) a single profile, based on a MAINTAINERS entry which includes the path 2) all of them, to study for various reasons The #2 case is helped by having them all in one directory with a single index.rst, etc. Then similar profiles are able to merge, etc. -- Kees Cook _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) 2019-09-17 3:35 ` [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) Kees Cook @ 2019-09-17 13:28 ` Mauro Carvalho Chehab 2019-09-17 16:33 ` Kees Cook 0 siblings, 1 reply; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-17 13:28 UTC (permalink / raw) To: Kees Cook; +Cc: ksummit-discuss, Linux Media Mailing List Hi Kees, Em Mon, 16 Sep 2019 20:35:45 -0700 Kees Cook <keescook@chromium.org> escreveu: > On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote: > > Document the basic policies of the media subsystem profile. > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> > > --- > > > > That's basically a modified version of: > > https://patchwork.linuxtv.org/patch/52999/ > > > > Applied to the new template > > > > Documentation/media/index.rst | 1 + > > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++ > > One idea I proposed to Dan at the Maintainer's Summit was to collect all > the profiles is a single directory in Documentation/, No matter where the profiles will physically be stored, its contents belong to subsystem-specific documentation, and should be visible at the same index file as the kAPI docs is located, as anyone interested on submitting patches for a subsystem should be aware about the subsystem specific policies and details. So, my vote is to store them at Documentation/*/<subsystem> (together with the kAPI book). > since there are > two ways someone would want to read profiles: > > 1) a single profile, based on a MAINTAINERS entry which includes the path That is the common case. The problem is that the MAINTAINERS file currently doesn't generate html output. This is not a problem for "old school" devs, but a newbie wanting to collaborate to a single specific subsystem may not notice - or understand - the importance of the MAINTAINERS file[1]. [1] btw, that's why I submitted a RFC, several years ago, a patch converting it to ReST - and later - another patch that would be parsing its contents and producing a ReST output. That's, by far, the most relevant usecase for the profiles, as the audience is the ~4k Kernel developers. > 2) all of them, to study for various reasons I suspect that only core people will have interest on study them. Those people are more skilled, and can easily find all those files with a simple grep: $ grep "^P:\s" MAINTAINERS|cut -d':' -f2- or $ git grep "^P:\s" MAINTAINERS|cut -d: -f3- If, for whatever reason, he would prefer an HTML output [1], he could even create an index file with all of those with something like: $ for i in $(grep "^P:\s" MAINTAINERS|cut -d':' -f2-); do j=${i/rst/html}; echo "<a href=\"$j\">$j</a><br/>"; done >Documentation/output/index_profiles.html We might, instead, teach the Documentation/Makefile to create something like the above, but, IMHO, that would just add more complexity to the build without a good reason. [1] I doubt that core devs would prefer seeing this in html form, but some variant of the above could be used, for example, to create symlinks for all profile docs into a "study" directory. > The #2 case is helped by having them all in one directory with a single > index.rst, etc. Then similar profiles are able to merge, etc. Thanks, Mauro _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) 2019-09-17 13:28 ` Mauro Carvalho Chehab @ 2019-09-17 16:33 ` Kees Cook 2019-09-18 11:23 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 82+ messages in thread From: Kees Cook @ 2019-09-17 16:33 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List On Tue, Sep 17, 2019 at 10:28:17AM -0300, Mauro Carvalho Chehab wrote: > No matter where the profiles will physically be stored, its contents belong > to subsystem-specific documentation, and should be visible at the same index > file as the kAPI docs is located, as anyone interested on submitting patches > for a subsystem should be aware about the subsystem specific policies and > details. That's a good point. I think your other suggestions below address my "find them all" case... > So, my vote is to store them at Documentation/*/<subsystem> (together > with the kAPI book). > > > since there are > > two ways someone would want to read profiles: > > > > 1) a single profile, based on a MAINTAINERS entry which includes the path > > That is the common case. The problem is that the MAINTAINERS file > currently doesn't generate html output. This is not a problem for > "old school" devs, but a newbie wanting to collaborate to a single > specific subsystem may not notice - or understand - the importance > of the MAINTAINERS file[1]. > > [1] btw, that's why I submitted a RFC, several years ago, a patch > converting it to ReST - and later - another patch that would be parsing > its contents and producing a ReST output. > > That's, by far, the most relevant usecase for the profiles, as the > audience is the ~4k Kernel developers. Oh yes, having a .rst of the MAINTAINERS file would be pretty great. Seems like it could just be a build target (and then dependency) for the sphinx targets? > > 2) all of them, to study for various reasons > > I suspect that only core people will have interest on study them. > > Those people are more skilled, and can easily find all those files with > a simple grep: > > $ grep "^P:\s" MAINTAINERS|cut -d':' -f2- > > or > > $ git grep "^P:\s" MAINTAINERS|cut -d: -f3- > > If, for whatever reason, he would prefer an HTML output [1], he could even > create an index file with all of those with something like: > > $ for i in $(grep "^P:\s" MAINTAINERS|cut -d':' -f2-); do j=${i/rst/html}; echo "<a href=\"$j\">$j</a><br/>"; done >Documentation/output/index_profiles.html > > We might, instead, teach the Documentation/Makefile to create something > like the above, but, IMHO, that would just add more complexity to the > build without a good reason. > > [1] I doubt that core devs would prefer seeing this in html form, but some > variant of the above could be used, for example, to create symlinks for > all profile docs into a "study" directory. > > > The #2 case is helped by having them all in one directory with a single > > index.rst, etc. Then similar profiles are able to merge, etc. Whatever the case, please don't let me distract from the actual content of these profiles: I think it's awesome to capture these details and makes my life so much easier. :) -- Kees Cook _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) 2019-09-17 16:33 ` Kees Cook @ 2019-09-18 11:23 ` Mauro Carvalho Chehab 2019-09-18 17:39 ` Kees Cook 2019-09-21 19:13 ` Jonathan Corbet 0 siblings, 2 replies; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-18 11:23 UTC (permalink / raw) To: Kees Cook; +Cc: ksummit-discuss, Linux Media Mailing List Em Tue, 17 Sep 2019 09:33:11 -0700 Kees Cook <keescook@chromium.org> escreveu: > On Tue, Sep 17, 2019 at 10:28:17AM -0300, Mauro Carvalho Chehab wrote: > > No matter where the profiles will physically be stored, its contents belong > > to subsystem-specific documentation, and should be visible at the same index > > file as the kAPI docs is located, as anyone interested on submitting patches > > for a subsystem should be aware about the subsystem specific policies and > > details. > > That's a good point. I think your other suggestions below address my > "find them all" case... > > > So, my vote is to store them at Documentation/*/<subsystem> (together > > with the kAPI book). > > > > > since there are > > > two ways someone would want to read profiles: > > > > > > 1) a single profile, based on a MAINTAINERS entry which includes the path > > > > That is the common case. The problem is that the MAINTAINERS file > > currently doesn't generate html output. This is not a problem for > > "old school" devs, but a newbie wanting to collaborate to a single > > specific subsystem may not notice - or understand - the importance > > of the MAINTAINERS file[1]. > > > > [1] btw, that's why I submitted a RFC, several years ago, a patch > > converting it to ReST - and later - another patch that would be parsing > > its contents and producing a ReST output. > > > > That's, by far, the most relevant usecase for the profiles, as the > > audience is the ~4k Kernel developers. > > Oh yes, having a .rst of the MAINTAINERS file would be pretty great. > Seems like it could just be a build target (and then dependency) for the > sphinx targets? You can't simply rename MAINTAINERS to .rst and let Sphinx handle it, as: - The instructions at the top will be badly parsed; - It will also parse wrong the entries. On the patches I wrote several years ago, I fixed the instructions to make them to produce something that would produce a good output. That's the easiest part. For the entries contents, the simplest solution would be something like: diff --git a/MAINTAINERS b/MAINTAINERS index 6b4bc320e6ab..ae2afb14ae01 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -147,4 +147,4 @@ F: drivers/net/ethernet/3com/3c59x.c -M: David Dillow <dave@thedillows.org> -L: netdev@vger.kernel.org -S: Maintained -F: drivers/net/ethernet/3com/typhoon* +:M: David Dillow <dave@thedillows.org> +:L: netdev@vger.kernel.org +:S: Maintained +:F: drivers/net/ethernet/3com/typhoon* A trivial change for a normal file, but doing this at MAINTAINERS will be really painful, as it will cause lots of conflicts. So, IMO, the best way to do it is to have a script (or to teach get_maintainers.pl) to produce a ReST output that would do the above. The latest RFC about that with I sent was this one: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html I would probably address this on a different way those days. A simple/lazy solution would be to apply the enclosed patch - or a variant of it that would place the contents of MAINTAINERS outside process/index.html, and add instructions about how to use get_maintainers.pl. Jon, Please let me know if you're willing to accept something like that. Thanks, Mauro [PATCH RFC] docs: process: add MAINTAINERS file contents Anyone working with the Kernel need to consider the contents of the MAINTAINERS file. So, add it to the ReST output. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index e2c9ffc682c5..22e5b42b8470 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -59,6 +59,9 @@ lack of a better place. volatile-considered-harmful clang-format +.. include:: ../../MAINTAINERS + :literal: + .. only:: subproject and html Indices _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) 2019-09-18 11:23 ` Mauro Carvalho Chehab @ 2019-09-18 17:39 ` Kees Cook 2019-09-18 18:35 ` Mauro Carvalho Chehab 2019-09-21 19:13 ` Jonathan Corbet 1 sibling, 1 reply; 82+ messages in thread From: Kees Cook @ 2019-09-18 17:39 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List On Wed, Sep 18, 2019 at 08:23:26AM -0300, Mauro Carvalho Chehab wrote: > You can't simply rename MAINTAINERS to .rst and let Sphinx handle it, Right! Sorry, I meant what you'd suggested earlier: having a script convert it at doc-build-time. > The latest RFC about that with I sent was this one: > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html Cool, I've found it on Lore now too: https://lore.kernel.org/lkml/20160923120733.546a4b7a@vento.lan/ I think having a script generate the entire thing might be better (instead of having duplicated instructions at the top of both files), which I see is what Joe suggested too. > +.. include:: ../../MAINTAINERS > + :literal: Nah, let's do a full make target as you'd suggested back in that thread. I'll give it a shot if you don't beat me to it. :) -- Kees Cook _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) 2019-09-18 17:39 ` Kees Cook @ 2019-09-18 18:35 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-18 18:35 UTC (permalink / raw) To: Kees Cook; +Cc: ksummit-discuss, Linux Media Mailing List Em Wed, 18 Sep 2019 10:39:32 -0700 Kees Cook <keescook@chromium.org> escreveu: > On Wed, Sep 18, 2019 at 08:23:26AM -0300, Mauro Carvalho Chehab wrote: > > You can't simply rename MAINTAINERS to .rst and let Sphinx handle it, > > Right! Sorry, I meant what you'd suggested earlier: having a script > convert it at doc-build-time. > > > The latest RFC about that with I sent was this one: > > > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html > > Cool, I've found it on Lore now too: > https://lore.kernel.org/lkml/20160923120733.546a4b7a@vento.lan/ > > I think having a script generate the entire thing might be better > (instead of having duplicated instructions at the top of both files), > which I see is what Joe suggested too. Yes, I agree that having the instructions duplicated was not the best idea :-) I guess I did it, on that time, just to experiment with the approach, but my plan were to avoid the duplication on some future patch. The big issue, on that point, was the usage of the programoutput extension. Some devs didn't like using it. > > > +.. include:: ../../MAINTAINERS > > + :literal: > > Nah, let's do a full make target as you'd suggested back in that thread. > > I'll give it a shot if you don't beat me to it. :) Yeah, please give it a shot. Feel free to reuse anything from my past approaches if needed. I suspect that, if we convert the first part of MAINTAINERS to ReST syntax, we could add something similar to this to Documentation/Makefile: $(BUILDDIR)/maintainers.rst: awk '{if (match($0,"----------")) exit; print}' MAINTAINERS >$(BUILDDIR)/maintainers.rst awk '/----------/{y=1;next}y' MAINTAINERS|sed -E 's,^(\w:),:\1,' >>$(BUILDDIR)/maintainers.rst Thanks, Mauro _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) 2019-09-18 11:23 ` Mauro Carvalho Chehab 2019-09-18 17:39 ` Kees Cook @ 2019-09-21 19:13 ` Jonathan Corbet 2019-09-21 19:45 ` Mauro Carvalho Chehab 2019-09-23 22:45 ` Kees Cook 1 sibling, 2 replies; 82+ messages in thread From: Jonathan Corbet @ 2019-09-21 19:13 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List On Wed, 18 Sep 2019 08:23:26 -0300 Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote: > A simple/lazy solution would be to apply the enclosed patch - or a > variant of it that would place the contents of MAINTAINERS outside > process/index.html, and add instructions about how to use > get_maintainers.pl. > > Jon, > > Please let me know if you're willing to accept something like that. [Sorry for the slowness, I'm kind of tuned out this week] I guess we could do that as a short-term thing. In truth, though, this thing is a database; printing it out linearly is perhaps not the best thing we could do. There should be better ways we could provide access to it. Also, that file is nearly 18K lines long. If some unsuspecting person generates a PDF and prints it, they're going to get something along the lines of 300 pages of MAINTAINERS, which may not quite be what they had in mind. It costs (almost) nothing to put that into HTML output, but other formats could be painful. So I dunno, we need to think this through a bit... jon _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) 2019-09-21 19:13 ` Jonathan Corbet @ 2019-09-21 19:45 ` Mauro Carvalho Chehab 2019-09-23 22:45 ` Kees Cook 1 sibling, 0 replies; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-21 19:45 UTC (permalink / raw) To: Jonathan Corbet; +Cc: ksummit-discuss, Linux Media Mailing List Em Sat, 21 Sep 2019 13:13:07 -0600 Jonathan Corbet <corbet@lwn.net> escreveu: > On Wed, 18 Sep 2019 08:23:26 -0300 > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote: > > > A simple/lazy solution would be to apply the enclosed patch - or a > > variant of it that would place the contents of MAINTAINERS outside > > process/index.html, and add instructions about how to use > > get_maintainers.pl. > > > > Jon, > > > > Please let me know if you're willing to accept something like that. > > [Sorry for the slowness, I'm kind of tuned out this week] > > I guess we could do that as a short-term thing. > > In truth, though, this thing is a database; printing it out linearly is > perhaps not the best thing we could do. There should be better ways we > could provide access to it. Yeah, as this is a database, instead of just outputting it on a formatted way, it is possible to generate other types of output. We could, for example, have an extension with would implement something like: .. maintainers:: <subdir> Which would call get-maintainers in order to parse a subsystem-specific set of entries and printing the maintainership details. This could be added at the subsystem-specific profile, for the subsystems that have it. > > Also, that file is nearly 18K lines long. If some unsuspecting person > generates a PDF and prints it, they're going to get something along the > lines of 300 pages of MAINTAINERS, which may not quite be what they had > in mind. It costs (almost) nothing to put that into HTML output, but > other formats could be painful. Even if we go for adding a Sphinx tag that would produce a parsed output for a system-specific profile, we'll still have several other subsystems that won't have a profile for a while, so I would still consider having somewhere an output with its contents. Yeah, someone might be tempted to print it, but we could place it on a separate PDF, in order to minimize the risks of someone printing the 300+ pages. > > So I dunno, we need to think this through a bit... > > jon Thanks, Mauro _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) 2019-09-21 19:13 ` Jonathan Corbet 2019-09-21 19:45 ` Mauro Carvalho Chehab @ 2019-09-23 22:45 ` Kees Cook 1 sibling, 0 replies; 82+ messages in thread From: Kees Cook @ 2019-09-23 22:45 UTC (permalink / raw) To: Jonathan Corbet Cc: Mauro Carvalho Chehab, ksummit-discuss, Linux Media Mailing List On Sat, Sep 21, 2019 at 01:13:07PM -0600, Jonathan Corbet wrote: > Also, that file is nearly 18K lines long. If some unsuspecting person > generates a PDF and prints it, they're going to get something along the > lines of 300 pages of MAINTAINERS, which may not quite be what they had > in mind. It costs (almost) nothing to put that into HTML output, but > other formats could be painful. Is this something that can be specifically excluded from the non-HTML outputs? (Or rather, specifically included in only the HTML output?) I don't see a way to do that exactly... maybe in my RFC only the html target would get the "real" file? -- Kees Cook _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-13 16:19 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Mauro Carvalho Chehab 2019-09-13 16:19 ` Mauro Carvalho Chehab 2019-09-17 3:35 ` [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) Kees Cook @ 2019-09-18 12:36 ` Laurent Pinchart 2019-09-18 13:57 ` Mauro Carvalho Chehab 2019-09-18 13:59 ` [Ksummit-discuss] [PATCH v2] " Mauro Carvalho Chehab 2 siblings, 2 replies; 82+ messages in thread From: Laurent Pinchart @ 2019-09-18 12:36 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List Hi Mauro, On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote: > Document the basic policies of the media subsystem profile. > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> > --- > > That's basically a modified version of: > https://patchwork.linuxtv.org/patch/52999/ > > Applied to the new template > > Documentation/media/index.rst | 1 + > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++ > MAINTAINERS | 1 + > 3 files changed, 142 insertions(+) > create mode 100644 Documentation/media/maintainer-entry-profile.rst > > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst > index 0301c25ff887..ac94685b822a 100644 > --- a/Documentation/media/index.rst > +++ b/Documentation/media/index.rst > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation > .. toctree:: > :maxdepth: 2 > > + maintainer-entry-profile > media_uapi > media_kapi > dvb-drivers/index > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst > new file mode 100644 > index 000000000000..81d3b0f9c36a > --- /dev/null > +++ b/Documentation/media/maintainer-entry-profile.rst > @@ -0,0 +1,140 @@ > +Media Subsystem Profile > +======================= > + > +Overview > +-------- > + > +The media subsystem cover support for a variety of devices: stream s/cover/covers/ > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC > +and media pipeline control. > + > +It covers, mainly, the contents of those directories: > + > + - drivers/media > + - drivers/staging/media > + - Documentation/media > + - include/media > + > +Both media userspace and Kernel APIs are documented and should be kept in > +sync with the API changes. It means that all patches that add new > +features to the subsystem should also bring changes to the corresponding > +API files. > + > +Also, patches for device drivers that changes the Open Firmware/Device > +Tree bindings should be reviewed by the Device Tree maintainers. You may want to make it clear that this covers bindings only, not driver code that parses the DT. I would just remove "for device drivers", as the rule should also apply to DT bindings documentation that is not driver-specific. > +Due to the size and wide scope of the media subsystem, media's > +maintainership model is to have sub-maintainers that have a broad > +knowledge of an specific aspect of the subsystem. It is a > +sub-maintainers task to review the patches, providing feedback to users s/sub-maintainers/sub-maintainer's/ > +if the patches are following the subsystem rules and are properly using > +the media internal and external APIs. > + > +Patches for the media subsystem should be sent to the media mailing list > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > +HTML will be automatically rejected by the mail server. There's no need > +to copy the maintainer or sub-maintainer(s). There's too much traffic on mailing lists for me to follow everything, I much prefer being CC'ed on patches. > +Media's workflow is heavily based on Patchwork, meaning that, once a patch > +is submitted, it should appear at: > + > + - https://patchwork.linuxtv.org/project/linux-media/list/ > + > +If it doesn't automatically appear there after a few minutes, then > +probably something got wrong on your submission. Please check if the > +email is in plain text only and if your emailer is not mangling with > +whitespaces before complaining or submit it again. > + > +Sub-maintainers > ++++++++++++++++ > + > +At the media subsystem, we have a group of senior developers that are How about "experienced" instead of "senior" ? Quality doesn't always come with age, neither for people nor wine :-) > +responsible for doing the code reviews at the drivers (called > +sub-maintainers), and another senior developer responsible for the > +subsystem as a hole. For core changes, whenever possible, multiple > +media (sub-)maintainers do the review. > + > +The sub-maintainers work on specific areas of the subsystem, as > +described below: > + > +Digital TV: > + Sean Young <sean@mess.org> > + > +HDMI CEC: > + Hans Verkuil <hverkuil@xs4all.nl> > + > +Media controller drivers: > + Laurent Pinchart <laurent.pinchart@ideasonboard.com> > + > +Remote Controllers: > + Sean Young <sean@mess.org> > + > +Sensor drivers: > + Sakari Ailus <sakari.ailus@linux.intel.com> > + > +V4L2 drivers: > + Hans Verkuil <hverkuil@xs4all.nl> > + > +Submit Checklist Addendum > +------------------------- > + > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ > +that should be used in order to check if the drivers are properly > +implementing the media APIs. > + > +Those tests need to be passed before the patches go upstream. s/need to be passed/need to pass/ > + > +Also, please notice that we build the Kernel with:: > + > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script > + > +Where the check script is:: > + > + #!/bin/bash > + /devel/smatch/smatch -p=kernel $@ >&2 > + /devel/sparse/sparse $@ >&2 > + > +Be sure to not introduce new warnings on your patches. While static analysers deliver value, I fear this is a high barrier to entry for new contributors. > + > +Key Cycle Dates > +--------------- > + > +New submissions can be sent at any time, but if they intend to hit the > +next merge window they should be sent before -rc5, and ideally stabilized > +in the linux-media branch by -rc6. > + > +Coding Style Addendum > +--------------------- > + > +Media development uses checkpatch on strict mode to verify the code style, e. g.:: > + > + $ ./script/checkpatch.pl --strict But we still accept some warnings. I think this should be documented. > + > +Review Cadence > +-------------- > + > +Provided that your patch is at https://patchwork.linuxtv.org, it should > +be sooner or later handled, so you don't need to re-submit a patch. > + > +Except for bug fixes, we don't usually add new patches to the development > +tree between -rc6 and the next -rc1. > + > +Please notice that the media subsystem is a high traffic one, so it > +could take a while for us to be able to review your patches. Feel free > +to ping if you don't get a feedback on a couple of weeks or to ask s/on a/in a/ > +other developers to publicly add Reviewed-by and, more importantly, > +Tested-by tags. > + > +Please notice that we expect a detailed description for Tested-by, s/notice/note/ > +identifying what boards were used at the test and what it was tested. > + > +Style Cleanup Patches > +--------------------- > + > +Style-cleanups are welcome when they come together with other changes > +at the files where the style changes will affect. > + > +We may accept pure standalone style-cleanups, but they should be grouped > +per directory. So, for example, if you're doing a cleanup at drivers > +under drivers/media, please send a single patch for all drivers under > +drivers/media/pci, another one for drivers/media/usb and so on. How about also stating that if the cleanup is low volume, a single patch for the whole subsystem is preferred ? I think that should actually be the rule, with a split to ease review only when the patch would be too big. > diff --git a/MAINTAINERS b/MAINTAINERS > index 7c62b45201d7..e7f44ec05a42 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10077,6 +10077,7 @@ W: https://linuxtv.org > Q: http://patchwork.kernel.org/project/linux-media/list/ > T: git git://linuxtv.org/media_tree.git > S: Maintained > +P: Documentation/media/maintainer-entry-profile.rst > F: Documentation/devicetree/bindings/media/ > F: Documentation/media/ > F: drivers/media/ -- Regards, Laurent Pinchart _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-18 12:36 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Laurent Pinchart @ 2019-09-18 13:57 ` Mauro Carvalho Chehab 2019-09-18 17:27 ` Laurent Pinchart 2019-09-19 6:56 ` Dan Carpenter 2019-09-18 13:59 ` [Ksummit-discuss] [PATCH v2] " Mauro Carvalho Chehab 1 sibling, 2 replies; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-18 13:57 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit-discuss, Linux Media Mailing List Em Wed, 18 Sep 2019 15:36:20 +0300 Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > Hi Mauro, > > On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote: > > Document the basic policies of the media subsystem profile. > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> > > --- > > > > That's basically a modified version of: > > https://patchwork.linuxtv.org/patch/52999/ > > > > Applied to the new template > > > > Documentation/media/index.rst | 1 + > > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++ > > MAINTAINERS | 1 + > > 3 files changed, 142 insertions(+) > > create mode 100644 Documentation/media/maintainer-entry-profile.rst > > > > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst > > index 0301c25ff887..ac94685b822a 100644 > > --- a/Documentation/media/index.rst > > +++ b/Documentation/media/index.rst > > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation > > .. toctree:: > > :maxdepth: 2 > > > > + maintainer-entry-profile > > media_uapi > > media_kapi > > dvb-drivers/index > > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst > > new file mode 100644 > > index 000000000000..81d3b0f9c36a > > --- /dev/null > > +++ b/Documentation/media/maintainer-entry-profile.rst > > @@ -0,0 +1,140 @@ > > +Media Subsystem Profile > > +======================= > > + > > +Overview > > +-------- > > + > > +The media subsystem cover support for a variety of devices: stream > > s/cover/covers/ > > > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC > > +and media pipeline control. > > + > > +It covers, mainly, the contents of those directories: > > + > > + - drivers/media > > + - drivers/staging/media > > + - Documentation/media > > + - include/media > > + > > +Both media userspace and Kernel APIs are documented and should be kept in > > +sync with the API changes. It means that all patches that add new > > +features to the subsystem should also bring changes to the corresponding > > +API files. > > + > > +Also, patches for device drivers that changes the Open Firmware/Device > > +Tree bindings should be reviewed by the Device Tree maintainers. > > You may want to make it clear that this covers bindings only, not driver > code that parses the DT. I would just remove "for device drivers", as > the rule should also apply to DT bindings documentation that is not > driver-specific. > > > +Due to the size and wide scope of the media subsystem, media's > > +maintainership model is to have sub-maintainers that have a broad > > +knowledge of an specific aspect of the subsystem. It is a > > +sub-maintainers task to review the patches, providing feedback to users > > s/sub-maintainers/sub-maintainer's/ > > > +if the patches are following the subsystem rules and are properly using > > +the media internal and external APIs. > > + > > +Patches for the media subsystem should be sent to the media mailing list > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > +HTML will be automatically rejected by the mail server. There's no need > > +to copy the maintainer or sub-maintainer(s). > > There's too much traffic on mailing lists for me to follow everything, I > much prefer being CC'ed on patches. Well, by using patchwork, the best is to take a look on it at least for the patches that you're interested. You could script something using pwclient in order to make it easier. Anyway, not sure if the other sub-maintainers see the same way. From my side, I prefer not to be c/c, as this is just more noise, as I just rely on patchwork for media patches. What about changing this to: Patches for the media subsystem should be sent to the media mailing list at linux-media@vger.kernel.org as plain text only e-mail. Emails with HTML will be automatically rejected by the mail server. It could be wise to also copy the sub-maintainer(s). > > > +Media's workflow is heavily based on Patchwork, meaning that, once a patch > > +is submitted, it should appear at: > > + > > + - https://patchwork.linuxtv.org/project/linux-media/list/ > > + > > +If it doesn't automatically appear there after a few minutes, then > > +probably something got wrong on your submission. Please check if the > > +email is in plain text only and if your emailer is not mangling with > > +whitespaces before complaining or submit it again. > > + > > +Sub-maintainers > > ++++++++++++++++ > > + > > +At the media subsystem, we have a group of senior developers that are > > How about "experienced" instead of "senior" ? Quality doesn't always > come with age, neither for people nor wine :-) > > > +responsible for doing the code reviews at the drivers (called > > +sub-maintainers), and another senior developer responsible for the > > +subsystem as a hole. For core changes, whenever possible, multiple > > +media (sub-)maintainers do the review. > > + > > +The sub-maintainers work on specific areas of the subsystem, as > > +described below: > > + > > +Digital TV: > > + Sean Young <sean@mess.org> > > + > > +HDMI CEC: > > + Hans Verkuil <hverkuil@xs4all.nl> > > + > > +Media controller drivers: > > + Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > + > > +Remote Controllers: > > + Sean Young <sean@mess.org> > > + > > +Sensor drivers: > > + Sakari Ailus <sakari.ailus@linux.intel.com> > > + > > +V4L2 drivers: > > + Hans Verkuil <hverkuil@xs4all.nl> > > + > > +Submit Checklist Addendum > > +------------------------- > > + > > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ > > +that should be used in order to check if the drivers are properly > > +implementing the media APIs. > > + > > +Those tests need to be passed before the patches go upstream. > > s/need to be passed/need to pass/ > > > + > > +Also, please notice that we build the Kernel with:: > > + > > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script > > + > > +Where the check script is:: > > + > > + #!/bin/bash > > + /devel/smatch/smatch -p=kernel $@ >&2 > > + /devel/sparse/sparse $@ >&2 > > + > > +Be sure to not introduce new warnings on your patches. > > While static analysers deliver value, I fear this is a high barrier to > entry for new contributors. Will change this to: Be sure to not introduce new warnings on your patches without a very good reason. Especially for new contributors, I really expect patches to not introduce new warnings, as it is usually a lot more painful to fix them later than to ask devs to do things right at the first place. > > > + > > +Key Cycle Dates > > +--------------- > > + > > +New submissions can be sent at any time, but if they intend to hit the > > +next merge window they should be sent before -rc5, and ideally stabilized > > +in the linux-media branch by -rc6. > > + > > +Coding Style Addendum > > +--------------------- > > + > > +Media development uses checkpatch on strict mode to verify the code style, e. g.:: > > + > > + $ ./script/checkpatch.pl --strict > > But we still accept some warnings. I think this should be documented. True, but not sure if we should enter into too specific details here. What about adding something like: Please notice that the goal here is to improve code readability. On a few cases, checkpatch may actually point to something that would look worse. So, you should use good send sense here, being prepared to justify any coding style decision. Please also notice that, on some cases, when you fix one issue, you may receive warnings about lines longer than 80 columns. It is fine to have longer lines if this means that other warnings will be fixed by that. Yet, if you're having more than 80 columns on a line, please consider simplifying the code - if too idented - or to use shorter names for variables. > > > + > > +Review Cadence > > +-------------- > > + > > +Provided that your patch is at https://patchwork.linuxtv.org, it should > > +be sooner or later handled, so you don't need to re-submit a patch. > > + > > +Except for bug fixes, we don't usually add new patches to the development > > +tree between -rc6 and the next -rc1. > > + > > +Please notice that the media subsystem is a high traffic one, so it > > +could take a while for us to be able to review your patches. Feel free > > +to ping if you don't get a feedback on a couple of weeks or to ask > > s/on a/in a/ > > > +other developers to publicly add Reviewed-by and, more importantly, > > +Tested-by tags. > > + > > +Please notice that we expect a detailed description for Tested-by, > > s/notice/note/ > > > +identifying what boards were used at the test and what it was tested. > > + > > +Style Cleanup Patches > > +--------------------- > > + > > +Style-cleanups are welcome when they come together with other changes > > +at the files where the style changes will affect. > > + > > +We may accept pure standalone style-cleanups, but they should be grouped > > +per directory. So, for example, if you're doing a cleanup at drivers > > +under drivers/media, please send a single patch for all drivers under > > +drivers/media/pci, another one for drivers/media/usb and so on. > > How about also stating that if the cleanup is low volume, a single patch > for the whole subsystem is preferred ? I think that should actually be > the rule, with a split to ease review only when the patch would be too > big. > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 7c62b45201d7..e7f44ec05a42 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -10077,6 +10077,7 @@ W: https://linuxtv.org > > Q: http://patchwork.kernel.org/project/linux-media/list/ > > T: git git://linuxtv.org/media_tree.git > > S: Maintained > > +P: Documentation/media/maintainer-entry-profile.rst > > F: Documentation/devicetree/bindings/media/ > > F: Documentation/media/ > > F: drivers/media/ > I'm enclosing the diff against the past version. I'll send a final version once the profiles patchset arrives upstream. Thanks, Mauro diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst index 81d3b0f9c36a..68d642abe2c1 100644 --- a/Documentation/media/maintainer-entry-profile.rst +++ b/Documentation/media/maintainer-entry-profile.rst @@ -4,7 +4,7 @@ Media Subsystem Profile Overview -------- -The media subsystem cover support for a variety of devices: stream +The media subsystem covers support for a variety of devices: stream capture, analog and digital TV, cameras, remote controllers, HDMI CEC and media pipeline control. @@ -20,20 +20,20 @@ sync with the API changes. It means that all patches that add new features to the subsystem should also bring changes to the corresponding API files. -Also, patches for device drivers that changes the Open Firmware/Device -Tree bindings should be reviewed by the Device Tree maintainers. +Also, patches that changes the Open Firmware/Device Tree bindings should +also be reviewed by the Device Tree maintainers. Due to the size and wide scope of the media subsystem, media's maintainership model is to have sub-maintainers that have a broad knowledge of an specific aspect of the subsystem. It is a -sub-maintainers task to review the patches, providing feedback to users +sub-maintainer's task to review the patches, providing feedback to users if the patches are following the subsystem rules and are properly using the media internal and external APIs. Patches for the media subsystem should be sent to the media mailing list at linux-media@vger.kernel.org as plain text only e-mail. Emails with -HTML will be automatically rejected by the mail server. There's no need -to copy the maintainer or sub-maintainer(s). +HTML will be automatically rejected by the mail server. It could be wise +to also copy the sub-maintainer(s). Media's workflow is heavily based on Patchwork, meaning that, once a patch is submitted, it should appear at: @@ -48,8 +48,8 @@ whitespaces before complaining or submit it again. Sub-maintainers +++++++++++++++ -At the media subsystem, we have a group of senior developers that are -responsible for doing the code reviews at the drivers (called +At the media subsystem, we have a group of experienced developers that +are responsible for doing the code reviews at the drivers (called sub-maintainers), and another senior developer responsible for the subsystem as a hole. For core changes, whenever possible, multiple media (sub-)maintainers do the review. @@ -82,7 +82,7 @@ There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ that should be used in order to check if the drivers are properly implementing the media APIs. -Those tests need to be passed before the patches go upstream. +Those tests need to pass before the patches go upstream. Also, please notice that we build the Kernel with:: @@ -94,7 +94,8 @@ Where the check script is:: /devel/smatch/smatch -p=kernel $@ >&2 /devel/sparse/sparse $@ >&2 -Be sure to not introduce new warnings on your patches. +Be sure to not introduce new warnings on your patches without a +very good reason. Key Cycle Dates --------------- @@ -110,6 +111,20 @@ Media development uses checkpatch on strict mode to verify the code style, e. g. $ ./script/checkpatch.pl --strict +Please notice that the goal here is to improve code readability. On a few +cases, checkpatch may actually point to something that would look worse. + +So, you should use good send sense here, being prepared to justify any +coding style decision. + +Please also notice that, on some cases, when you fix one issue, you may +receive warnings about lines longer than 80 columns. It is fine to have +longer lines if this means that other warnings will be fixed by that. + +Yet, if you're having more than 80 columns on a line, please consider +simplifying the code - if too idented - or to use shorter names for +variables. + Review Cadence -------------- @@ -121,11 +136,11 @@ tree between -rc6 and the next -rc1. Please notice that the media subsystem is a high traffic one, so it could take a while for us to be able to review your patches. Feel free -to ping if you don't get a feedback on a couple of weeks or to ask +to ping if you don't get a feedback in a couple of weeks or to ask other developers to publicly add Reviewed-by and, more importantly, Tested-by tags. -Please notice that we expect a detailed description for Tested-by, +Please note that we expect a detailed description for Tested-by, identifying what boards were used at the test and what it was tested. Style Cleanup Patches @@ -134,7 +149,9 @@ Style Cleanup Patches Style-cleanups are welcome when they come together with other changes at the files where the style changes will affect. -We may accept pure standalone style-cleanups, but they should be grouped -per directory. So, for example, if you're doing a cleanup at drivers -under drivers/media, please send a single patch for all drivers under -drivers/media/pci, another one for drivers/media/usb and so on. +We may accept pure standalone style-cleanups, but they should ideally +be one patch for the hole subsystem (if the cleanup is low volume), +or at least be grouped per directory. So, for example, if you're doing +big cleanup changes at drivers under drivers/media, please send a single +patch for all drivers under drivers/media/pci, another one for +drivers/media/usb and so on. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-18 13:57 ` Mauro Carvalho Chehab @ 2019-09-18 17:27 ` Laurent Pinchart 2019-09-18 18:48 ` Mauro Carvalho Chehab 2019-09-19 6:56 ` Dan Carpenter 1 sibling, 1 reply; 82+ messages in thread From: Laurent Pinchart @ 2019-09-18 17:27 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List Hi Mauro, On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: > Em Wed, 18 Sep 2019 15:36:20 +0300 Laurent Pinchart escreveu: > > On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote: > > > Document the basic policies of the media subsystem profile. > > > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> > > > --- > > > > > > That's basically a modified version of: > > > https://patchwork.linuxtv.org/patch/52999/ > > > > > > Applied to the new template > > > > > > Documentation/media/index.rst | 1 + > > > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++ > > > MAINTAINERS | 1 + > > > 3 files changed, 142 insertions(+) > > > create mode 100644 Documentation/media/maintainer-entry-profile.rst > > > > > > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst > > > index 0301c25ff887..ac94685b822a 100644 > > > --- a/Documentation/media/index.rst > > > +++ b/Documentation/media/index.rst > > > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation > > > .. toctree:: > > > :maxdepth: 2 > > > > > > + maintainer-entry-profile > > > media_uapi > > > media_kapi > > > dvb-drivers/index > > > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst > > > new file mode 100644 > > > index 000000000000..81d3b0f9c36a > > > --- /dev/null > > > +++ b/Documentation/media/maintainer-entry-profile.rst > > > @@ -0,0 +1,140 @@ > > > +Media Subsystem Profile > > > +======================= > > > + > > > +Overview > > > +-------- > > > + > > > +The media subsystem cover support for a variety of devices: stream > > > > s/cover/covers/ > > > > > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC > > > +and media pipeline control. > > > + > > > +It covers, mainly, the contents of those directories: > > > + > > > + - drivers/media > > > + - drivers/staging/media > > > + - Documentation/media > > > + - include/media > > > + > > > +Both media userspace and Kernel APIs are documented and should be kept in > > > +sync with the API changes. It means that all patches that add new > > > +features to the subsystem should also bring changes to the corresponding > > > +API files. > > > + > > > +Also, patches for device drivers that changes the Open Firmware/Device > > > +Tree bindings should be reviewed by the Device Tree maintainers. > > > > You may want to make it clear that this covers bindings only, not driver > > code that parses the DT. I would just remove "for device drivers", as > > the rule should also apply to DT bindings documentation that is not > > driver-specific. > > > > > +Due to the size and wide scope of the media subsystem, media's > > > +maintainership model is to have sub-maintainers that have a broad > > > +knowledge of an specific aspect of the subsystem. It is a > > > +sub-maintainers task to review the patches, providing feedback to users > > > > s/sub-maintainers/sub-maintainer's/ > > > > > +if the patches are following the subsystem rules and are properly using > > > +the media internal and external APIs. > > > + > > > +Patches for the media subsystem should be sent to the media mailing list > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > +HTML will be automatically rejected by the mail server. There's no need > > > +to copy the maintainer or sub-maintainer(s). > > > > There's too much traffic on mailing lists for me to follow everything, I > > much prefer being CC'ed on patches. > > Well, by using patchwork, the best is to take a look on it at least for > the patches that you're interested. You could script something using > pwclient in order to make it easier. > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > I prefer not to be c/c, as this is just more noise, as I just rely on > patchwork for media patches. What about changing this to: > > Patches for the media subsystem should be sent to the media mailing list > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > HTML will be automatically rejected by the mail server. It could be wise > to also copy the sub-maintainer(s). That works for me. As this is really a personal preference, is there a way it could be encoded in MAINTAINERS in a per-person fashion ? Something that would allow you to opt-out from CC from linux-media (but possibly opt-in for other parts of the kernel), and allow me to opt-in for the drivers I maintain ? > > > +Media's workflow is heavily based on Patchwork, meaning that, once a patch > > > +is submitted, it should appear at: > > > + > > > + - https://patchwork.linuxtv.org/project/linux-media/list/ > > > + > > > +If it doesn't automatically appear there after a few minutes, then > > > +probably something got wrong on your submission. Please check if the > > > +email is in plain text only and if your emailer is not mangling with > > > +whitespaces before complaining or submit it again. > > > + > > > +Sub-maintainers > > > ++++++++++++++++ > > > + > > > +At the media subsystem, we have a group of senior developers that are > > > > How about "experienced" instead of "senior" ? Quality doesn't always > > come with age, neither for people nor wine :-) > > > > > +responsible for doing the code reviews at the drivers (called > > > +sub-maintainers), and another senior developer responsible for the > > > +subsystem as a hole. For core changes, whenever possible, multiple > > > +media (sub-)maintainers do the review. > > > + > > > +The sub-maintainers work on specific areas of the subsystem, as > > > +described below: > > > + > > > +Digital TV: > > > + Sean Young <sean@mess.org> > > > + > > > +HDMI CEC: > > > + Hans Verkuil <hverkuil@xs4all.nl> > > > + > > > +Media controller drivers: > > > + Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > + > > > +Remote Controllers: > > > + Sean Young <sean@mess.org> > > > + > > > +Sensor drivers: > > > + Sakari Ailus <sakari.ailus@linux.intel.com> > > > + > > > +V4L2 drivers: > > > + Hans Verkuil <hverkuil@xs4all.nl> > > > + > > > +Submit Checklist Addendum > > > +------------------------- > > > + > > > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ > > > +that should be used in order to check if the drivers are properly > > > +implementing the media APIs. > > > + > > > +Those tests need to be passed before the patches go upstream. > > > > s/need to be passed/need to pass/ > > > > > + > > > +Also, please notice that we build the Kernel with:: > > > + > > > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script > > > + > > > +Where the check script is:: > > > + > > > + #!/bin/bash > > > + /devel/smatch/smatch -p=kernel $@ >&2 > > > + /devel/sparse/sparse $@ >&2 > > > + > > > +Be sure to not introduce new warnings on your patches. > > > > While static analysers deliver value, I fear this is a high barrier to > > entry for new contributors. > > Will change this to: > > Be sure to not introduce new warnings on your patches without a > very good reason. > > Especially for new contributors, I really expect patches to not introduce > new warnings, as it is usually a lot more painful to fix them later than > to ask devs to do things right at the first place. I fully agree with the goal, but asking a drive-by contributor, who usually has to go through issues with sending patches through e-mail already, to install smatch and sparse and use them, is setting the bar high. I think automating those checks is the way to go. > > > + > > > +Key Cycle Dates > > > +--------------- > > > + > > > +New submissions can be sent at any time, but if they intend to hit the > > > +next merge window they should be sent before -rc5, and ideally stabilized > > > +in the linux-media branch by -rc6. > > > + > > > +Coding Style Addendum > > > +--------------------- > > > + > > > +Media development uses checkpatch on strict mode to verify the code style, e. g.:: > > > + > > > + $ ./script/checkpatch.pl --strict > > > > But we still accept some warnings. I think this should be documented. > > True, but not sure if we should enter into too specific details here. > > What about adding something like: > > Please notice that the goal here is to improve code readability. On a few > cases, checkpatch may actually point to something that would look worse. > > So, you should use good send sense here, being prepared to justify any s/send sense/sense/ > coding style decision. "being prepared to justify" sounds a bit harsh :-) But the general message is good. > > Please also notice that, on some cases, when you fix one issue, you may > receive warnings about lines longer than 80 columns. It is fine to have > longer lines if this means that other warnings will be fixed by that. > > Yet, if you're having more than 80 columns on a line, please consider > simplifying the code - if too idented - or to use shorter names for > variables. That's already quite specific for my taste. We can keep it as-is if you think it's fine, but we clearly shouldn't go into more details. > > > + > > > +Review Cadence > > > +-------------- > > > + > > > +Provided that your patch is at https://patchwork.linuxtv.org, it should > > > +be sooner or later handled, so you don't need to re-submit a patch. > > > + > > > +Except for bug fixes, we don't usually add new patches to the development > > > +tree between -rc6 and the next -rc1. > > > + > > > +Please notice that the media subsystem is a high traffic one, so it > > > +could take a while for us to be able to review your patches. Feel free > > > +to ping if you don't get a feedback on a couple of weeks or to ask > > > > s/on a/in a/ > > > > > +other developers to publicly add Reviewed-by and, more importantly, > > > +Tested-by tags. > > > + > > > +Please notice that we expect a detailed description for Tested-by, > > > > s/notice/note/ > > > > > +identifying what boards were used at the test and what it was tested. > > > + > > > +Style Cleanup Patches > > > +--------------------- > > > + > > > +Style-cleanups are welcome when they come together with other changes > > > +at the files where the style changes will affect. > > > + > > > +We may accept pure standalone style-cleanups, but they should be grouped > > > +per directory. So, for example, if you're doing a cleanup at drivers > > > +under drivers/media, please send a single patch for all drivers under > > > +drivers/media/pci, another one for drivers/media/usb and so on. > > > > How about also stating that if the cleanup is low volume, a single patch > > for the whole subsystem is preferred ? I think that should actually be > > the rule, with a split to ease review only when the patch would be too > > big. > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 7c62b45201d7..e7f44ec05a42 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -10077,6 +10077,7 @@ W: https://linuxtv.org > > > Q: http://patchwork.kernel.org/project/linux-media/list/ > > > T: git git://linuxtv.org/media_tree.git > > > S: Maintained > > > +P: Documentation/media/maintainer-entry-profile.rst > > > F: Documentation/devicetree/bindings/media/ > > > F: Documentation/media/ > > > F: drivers/media/ > > > > I'm enclosing the diff against the past version. I'll send a final version > once the profiles patchset arrives upstream. > > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst > index 81d3b0f9c36a..68d642abe2c1 100644 > --- a/Documentation/media/maintainer-entry-profile.rst > +++ b/Documentation/media/maintainer-entry-profile.rst > @@ -4,7 +4,7 @@ Media Subsystem Profile > Overview > -------- > > -The media subsystem cover support for a variety of devices: stream > +The media subsystem covers support for a variety of devices: stream > capture, analog and digital TV, cameras, remote controllers, HDMI CEC > and media pipeline control. > > @@ -20,20 +20,20 @@ sync with the API changes. It means that all patches that add new > features to the subsystem should also bring changes to the corresponding > API files. > > -Also, patches for device drivers that changes the Open Firmware/Device > -Tree bindings should be reviewed by the Device Tree maintainers. > +Also, patches that changes the Open Firmware/Device Tree bindings should > +also be reviewed by the Device Tree maintainers. > > Due to the size and wide scope of the media subsystem, media's > maintainership model is to have sub-maintainers that have a broad > knowledge of an specific aspect of the subsystem. It is a > -sub-maintainers task to review the patches, providing feedback to users > +sub-maintainer's task to review the patches, providing feedback to users > if the patches are following the subsystem rules and are properly using > the media internal and external APIs. > > Patches for the media subsystem should be sent to the media mailing list > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > -HTML will be automatically rejected by the mail server. There's no need > -to copy the maintainer or sub-maintainer(s). > +HTML will be automatically rejected by the mail server. It could be wise > +to also copy the sub-maintainer(s). > > Media's workflow is heavily based on Patchwork, meaning that, once a patch > is submitted, it should appear at: > @@ -48,8 +48,8 @@ whitespaces before complaining or submit it again. > Sub-maintainers > +++++++++++++++ > > -At the media subsystem, we have a group of senior developers that are > -responsible for doing the code reviews at the drivers (called > +At the media subsystem, we have a group of experienced developers that > +are responsible for doing the code reviews at the drivers (called > sub-maintainers), and another senior developer responsible for the > subsystem as a hole. For core changes, whenever possible, multiple > media (sub-)maintainers do the review. > @@ -82,7 +82,7 @@ There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ > that should be used in order to check if the drivers are properly > implementing the media APIs. > > -Those tests need to be passed before the patches go upstream. > +Those tests need to pass before the patches go upstream. > > Also, please notice that we build the Kernel with:: > > @@ -94,7 +94,8 @@ Where the check script is:: > /devel/smatch/smatch -p=kernel $@ >&2 > /devel/sparse/sparse $@ >&2 > > -Be sure to not introduce new warnings on your patches. > +Be sure to not introduce new warnings on your patches without a > +very good reason. > > Key Cycle Dates > --------------- > @@ -110,6 +111,20 @@ Media development uses checkpatch on strict mode to verify the code style, e. g. > > $ ./script/checkpatch.pl --strict > > +Please notice that the goal here is to improve code readability. On a few > +cases, checkpatch may actually point to something that would look worse. > + > +So, you should use good send sense here, being prepared to justify any > +coding style decision. > + > +Please also notice that, on some cases, when you fix one issue, you may > +receive warnings about lines longer than 80 columns. It is fine to have > +longer lines if this means that other warnings will be fixed by that. > + > +Yet, if you're having more than 80 columns on a line, please consider > +simplifying the code - if too idented - or to use shorter names for > +variables. > + > Review Cadence > -------------- > > @@ -121,11 +136,11 @@ tree between -rc6 and the next -rc1. > > Please notice that the media subsystem is a high traffic one, so it > could take a while for us to be able to review your patches. Feel free > -to ping if you don't get a feedback on a couple of weeks or to ask > +to ping if you don't get a feedback in a couple of weeks or to ask > other developers to publicly add Reviewed-by and, more importantly, > Tested-by tags. > > -Please notice that we expect a detailed description for Tested-by, > +Please note that we expect a detailed description for Tested-by, > identifying what boards were used at the test and what it was tested. > > Style Cleanup Patches > @@ -134,7 +149,9 @@ Style Cleanup Patches > Style-cleanups are welcome when they come together with other changes > at the files where the style changes will affect. > > -We may accept pure standalone style-cleanups, but they should be grouped > -per directory. So, for example, if you're doing a cleanup at drivers > -under drivers/media, please send a single patch for all drivers under > -drivers/media/pci, another one for drivers/media/usb and so on. > +We may accept pure standalone style-cleanups, but they should ideally > +be one patch for the hole subsystem (if the cleanup is low volume), s/hole/whole/ > +or at least be grouped per directory. So, for example, if you're doing > +big cleanup changes at drivers under drivers/media, please send a single > +patch for all drivers under drivers/media/pci, another one for > +drivers/media/usb and so on. -- Regards, Laurent Pinchart _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-18 17:27 ` Laurent Pinchart @ 2019-09-18 18:48 ` Mauro Carvalho Chehab 2019-09-19 7:08 ` Dan Carpenter 0 siblings, 1 reply; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-18 18:48 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit-discuss, Linux Media Mailing List Em Wed, 18 Sep 2019 20:27:05 +0300 Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > > I prefer not to be c/c, as this is just more noise, as I just rely on > > patchwork for media patches. What about changing this to: > > > > Patches for the media subsystem should be sent to the media mailing list > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > HTML will be automatically rejected by the mail server. It could be wise > > to also copy the sub-maintainer(s). > > That works for me. As this is really a personal preference, is there a > way it could be encoded in MAINTAINERS in a per-person fashion ? > Something that would allow you to opt-out from CC from linux-media (but > possibly opt-in for other parts of the kernel), and allow me to opt-in > for the drivers I maintain ? I don't think so. Perhaps we could add, instead, something like that at the sub-maintainers section of the profile. > > > > +Submit Checklist Addendum > > > > +------------------------- > > > > + > > > > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ > > > > +that should be used in order to check if the drivers are properly > > > > +implementing the media APIs. > > > > + > > > > +Those tests need to be passed before the patches go upstream. > > > > > > s/need to be passed/need to pass/ > > > > > > > + > > > > +Also, please notice that we build the Kernel with:: > > > > + > > > > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script > > > > + > > > > +Where the check script is:: > > > > + > > > > + #!/bin/bash > > > > + /devel/smatch/smatch -p=kernel $@ >&2 > > > > + /devel/sparse/sparse $@ >&2 > > > > + > > > > +Be sure to not introduce new warnings on your patches. > > > > > > While static analysers deliver value, I fear this is a high barrier to > > > entry for new contributors. > > > > Will change this to: > > > > Be sure to not introduce new warnings on your patches without a > > very good reason. > > > > Especially for new contributors, I really expect patches to not introduce > > new warnings, as it is usually a lot more painful to fix them later than > > to ask devs to do things right at the first place. > > I fully agree with the goal, but asking a drive-by contributor, who > usually has to go through issues with sending patches through e-mail > already, to install smatch and sparse and use them, is setting the bar > high. I think automating those checks is the way to go. Yeah, I have plans to automate it, the same way we did for pull requests. I'm planning to do that later, after upgrading patchwork to the current upstream version (with requires upgrading some libraries too at the server). In any case, having this at the profile is a reminder for whomever is submitting a patch that it should be clean for static analyzers too. > > > > +Coding Style Addendum > > > > +--------------------- > > > > + > > > > +Media development uses checkpatch on strict mode to verify the code style, e. g.:: > > > > + > > > > + $ ./script/checkpatch.pl --strict > > > > > > But we still accept some warnings. I think this should be documented. > > > > True, but not sure if we should enter into too specific details here. > > > > What about adding something like: > > > > Please notice that the goal here is to improve code readability. On a few > > cases, checkpatch may actually point to something that would look worse. > > > > So, you should use good send sense here, being prepared to justify any > > s/send sense/sense/ Gah... where this "send" came from??? :-p > > > coding style decision. > > "being prepared to justify" sounds a bit harsh :-) But the general > message is good. Any suggestions for a lighter text with similar meaning? :-) > > Please also notice that, on some cases, when you fix one issue, you may > > receive warnings about lines longer than 80 columns. It is fine to have > > longer lines if this means that other warnings will be fixed by that. > > > > Yet, if you're having more than 80 columns on a line, please consider > > simplifying the code - if too idented - or to use shorter names for > > variables. > > That's already quite specific for my taste. We can keep it as-is if you > think it's fine, but we clearly shouldn't go into more details. Yeah, I see. Yet, IMHO, we should either not add anything about checkpatch warnings that might not be relevant or add something similar like the above. Thanks, Mauro _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-18 18:48 ` Mauro Carvalho Chehab @ 2019-09-19 7:08 ` Dan Carpenter 2019-09-20 5:29 ` Joe Perches 0 siblings, 1 reply; 82+ messages in thread From: Dan Carpenter @ 2019-09-19 7:08 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List On Wed, Sep 18, 2019 at 03:48:31PM -0300, Mauro Carvalho Chehab wrote: > Em Wed, 18 Sep 2019 20:27:05 +0300 > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > > > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > > > I prefer not to be c/c, as this is just more noise, as I just rely on > > > patchwork for media patches. What about changing this to: > > > > > > Patches for the media subsystem should be sent to the media mailing list > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > HTML will be automatically rejected by the mail server. It could be wise > > > to also copy the sub-maintainer(s). > > > > That works for me. As this is really a personal preference, is there a > > way it could be encoded in MAINTAINERS in a per-person fashion ? > > Something that would allow you to opt-out from CC from linux-media (but > > possibly opt-in for other parts of the kernel), and allow me to opt-in > > for the drivers I maintain ? > > I don't think so. Perhaps we could add, instead, something like that at the > sub-maintainers section of the profile. Of course there is a way to add yourself as a maintainer for a specific .c file... Maybe people feel like MAINTAINERS is too crowded? We could update get_maintainer.pl to grep the .c files for a specific tag instead of putting everything in a centralized MAINTAINERS file. But it doesn't make sense to try store that information MY BRAIN! I can't remember anything from one minute to the next so I have no idea who maintains media submodules... regards, dan carpenter _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-19 7:08 ` Dan Carpenter @ 2019-09-20 5:29 ` Joe Perches 2019-09-20 14:09 ` Daniel Vetter 0 siblings, 1 reply; 82+ messages in thread From: Joe Perches @ 2019-09-20 5:29 UTC (permalink / raw) To: Dan Carpenter, Mauro Carvalho Chehab Cc: ksummit-discuss, Linux Media Mailing List On Thu, 2019-09-19 at 10:08 +0300, Dan Carpenter wrote: > On Wed, Sep 18, 2019 at 03:48:31PM -0300, Mauro Carvalho Chehab wrote: > > Em Wed, 18 Sep 2019 20:27:05 +0300 > > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > > > > > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > > > > I prefer not to be c/c, as this is just more noise, as I just rely on > > > > patchwork for media patches. What about changing this to: > > > > > > > > Patches for the media subsystem should be sent to the media mailing list > > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > > HTML will be automatically rejected by the mail server. It could be wise > > > > to also copy the sub-maintainer(s). > > > > > > That works for me. As this is really a personal preference, is there a > > > way it could be encoded in MAINTAINERS in a per-person fashion ? > > > Something that would allow you to opt-out from CC from linux-media (but > > > possibly opt-in for other parts of the kernel), and allow me to opt-in > > > for the drivers I maintain ? > > > > I don't think so. Perhaps we could add, instead, something like that at the > > sub-maintainers section of the profile. > > Of course there is a way to add yourself as a maintainer for a specific > .c file... Maybe people feel like MAINTAINERS is too crowded? > > We could update get_maintainer.pl to grep the .c files for a specific > tag instead of putting everything in a centralized MAINTAINERS file. Another option is to split the MAINTAINERS file into multiple distributed files. get_maintainer.pl already supports that. https://lwn.net/Articles/730509/ https://lore.kernel.org/lkml/1501350403.5368.65.camel@perches.com/ > But it doesn't make sense to try store that information MY BRAIN! I > can't remember anything from one minute to the next so I have no idea > who maintains media submodules... Nor I. Nor should I have to. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-20 5:29 ` Joe Perches @ 2019-09-20 14:09 ` Daniel Vetter 0 siblings, 0 replies; 82+ messages in thread From: Daniel Vetter @ 2019-09-20 14:09 UTC (permalink / raw) To: Joe Perches Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List On Fri, Sep 20, 2019 at 1:27 PM Joe Perches <joe@perches.com> wrote: > > On Thu, 2019-09-19 at 10:08 +0300, Dan Carpenter wrote: > > On Wed, Sep 18, 2019 at 03:48:31PM -0300, Mauro Carvalho Chehab wrote: > > > Em Wed, 18 Sep 2019 20:27:05 +0300 > > > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > > > > > > > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > > > > > I prefer not to be c/c, as this is just more noise, as I just rely on > > > > > patchwork for media patches. What about changing this to: > > > > > > > > > > Patches for the media subsystem should be sent to the media mailing list > > > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > > > HTML will be automatically rejected by the mail server. It could be wise > > > > > to also copy the sub-maintainer(s). > > > > > > > > That works for me. As this is really a personal preference, is there a > > > > way it could be encoded in MAINTAINERS in a per-person fashion ? > > > > Something that would allow you to opt-out from CC from linux-media (but > > > > possibly opt-in for other parts of the kernel), and allow me to opt-in > > > > for the drivers I maintain ? > > > > > > I don't think so. Perhaps we could add, instead, something like that at the > > > sub-maintainers section of the profile. > > > > Of course there is a way to add yourself as a maintainer for a specific > > .c file... Maybe people feel like MAINTAINERS is too crowded? > > > > We could update get_maintainer.pl to grep the .c files for a specific > > tag instead of putting everything in a centralized MAINTAINERS file. > > Another option is to split the MAINTAINERS file into multiple > distributed files. get_maintainer.pl already supports that. > > https://lwn.net/Articles/730509/ > https://lore.kernel.org/lkml/1501350403.5368.65.camel@perches.com/ Oh I missed that entirely. Can we roll this out now in subsystems? I'd really like to move all the gpu related MAINTAINERS entries into drivers/gpu. The one file in the root is unmangeable big and git blame takes forever. Ofc splitting it isn't an immediate fix, but long term should be easier. I thought Linus planned to just do that split (at least the first level or so) after an -rc1? -Daniel > > But it doesn't make sense to try store that information MY BRAIN! I > > can't remember anything from one minute to the next so I have no idea > > who maintains media submodules... > > Nor I. Nor should I have to. > > > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-18 13:57 ` Mauro Carvalho Chehab 2019-09-18 17:27 ` Laurent Pinchart @ 2019-09-19 6:56 ` Dan Carpenter 2019-09-19 7:22 ` Geert Uytterhoeven ` (2 more replies) 1 sibling, 3 replies; 82+ messages in thread From: Dan Carpenter @ 2019-09-19 6:56 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: > > > +Patches for the media subsystem should be sent to the media mailing list > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > +HTML will be automatically rejected by the mail server. There's no need > > > +to copy the maintainer or sub-maintainer(s). > > > > There's too much traffic on mailing lists for me to follow everything, I > > much prefer being CC'ed on patches. > > Well, by using patchwork, the best is to take a look on it at least for > the patches that you're interested. You could script something using > pwclient in order to make it easier. > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > I prefer not to be c/c, as this is just more noise, as I just rely on > patchwork for media patches. What about changing this to: > > Patches for the media subsystem should be sent to the media mailing list > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > HTML will be automatically rejected by the mail server. It could be wise > to also copy the sub-maintainer(s). The documentation should say "Use get_maintainer.pl" and do what it says. Everything else is too complicated. Occasionally staging maintainers will complain that they aren't CC'd even though the staging/driver/README says to CC them and I am tell them "No, the responsibility is for you to add yourself to MAINTAINERS. It doesn't matter what the documentation says, you messed up so you need to stop getting annoyed with newbies for not reading the documentation when it's your fault you weren't CC'd." When I sent a patch, I use get_maintainer.pl then I add whoever the wrote the commit from the Fixes tag. Then I remove Colin King and Kees Cook from the CC list because they worked all over the tree and I know them. I also normally remove LKML if there is another mailing list but at least one subsystem uses LKML for patchwork so this isn't safe. So the safest instructions are "Use get_matainer.pl and add the person who wrote the commit in the Fixes tag". regards, dan carpenter _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-19 6:56 ` Dan Carpenter @ 2019-09-19 7:22 ` Geert Uytterhoeven 2019-09-19 8:49 ` Jani Nikula 2019-09-20 14:53 ` Laurent Pinchart 2019-09-19 9:52 ` Mauro Carvalho Chehab 2019-09-25 17:13 ` Joe Perches 2 siblings, 2 replies; 82+ messages in thread From: Geert Uytterhoeven @ 2019-09-19 7:22 UTC (permalink / raw) To: Dan Carpenter; +Cc: Mauro Carvalho Chehab, ksummit, Linux Media Mailing List On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote: > On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: > > > > +Patches for the media subsystem should be sent to the media mailing list > > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > > +HTML will be automatically rejected by the mail server. There's no need > > > > +to copy the maintainer or sub-maintainer(s). > > > > > > There's too much traffic on mailing lists for me to follow everything, I > > > much prefer being CC'ed on patches. > > > > Well, by using patchwork, the best is to take a look on it at least for > > the patches that you're interested. You could script something using > > pwclient in order to make it easier. > > > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > > I prefer not to be c/c, as this is just more noise, as I just rely on > > patchwork for media patches. What about changing this to: > > > > Patches for the media subsystem should be sent to the media mailing list > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > HTML will be automatically rejected by the mail server. It could be wise > > to also copy the sub-maintainer(s). > > The documentation should say "Use get_maintainer.pl" and do what it > says. Everything else is too complicated. +1 > When I sent a patch, I use get_maintainer.pl then I add whoever the > wrote the commit from the Fixes tag. Then I remove Colin King and Kees > Cook from the CC list because they worked all over the tree and I know > them. I also normally remove LKML if there is another mailing list but > at least one subsystem uses LKML for patchwork so this isn't safe. > > So the safest instructions are "Use get_matainer.pl and add the person > who wrote the commit in the Fixes tag". Better: perhaps get_maintainer.pl can be taught to add the author of the commit pointed to by the Fixes tag, if present? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-19 7:22 ` Geert Uytterhoeven @ 2019-09-19 8:49 ` Jani Nikula 2019-09-19 8:58 ` Geert Uytterhoeven 2019-09-20 14:53 ` Laurent Pinchart 1 sibling, 1 reply; 82+ messages in thread From: Jani Nikula @ 2019-09-19 8:49 UTC (permalink / raw) To: Geert Uytterhoeven, Dan Carpenter Cc: Mauro Carvalho Chehab, ksummit, Linux Media Mailing List On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote: >> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: >> When I sent a patch, I use get_maintainer.pl then I add whoever the >> wrote the commit from the Fixes tag. Then I remove Colin King and Kees >> Cook from the CC list because they worked all over the tree and I know >> them. I also normally remove LKML if there is another mailing list but >> at least one subsystem uses LKML for patchwork so this isn't safe. >> >> So the safest instructions are "Use get_matainer.pl and add the person >> who wrote the commit in the Fixes tag". > > Better: perhaps get_maintainer.pl can be taught to add the author of the > commit pointed to by the Fixes tag, if present? The drm maintainer tools [1] have that, with Cc's and reviewers picked up, and appropriate Cc: stable added. On a random commit from v5.3: $ dim fixes 61f7f7c8f978b1c0d80e43c83b7d110ca0496eb4 Fixes: 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist") Cc: stable@vger.kernel.org Cc: Daniel Drake <drake@endlessm.com> Cc: Ian W MORRISON <ianwmorrison@gmail.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: linux-gpio@vger.kernel.org Cc: linux-acpi@vger.kernel.org Cc: <stable@vger.kernel.org> # v5.3+ I'm sure it could be massively improved, but it does give you the initial list that's easy to trim. BR, Jani. [1] https://gitlab.freedesktop.org/drm/maintainer-tools/blob/master/dim#L2398 -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-19 8:49 ` Jani Nikula @ 2019-09-19 8:58 ` Geert Uytterhoeven 2019-09-19 9:52 ` Jani Nikula 0 siblings, 1 reply; 82+ messages in thread From: Geert Uytterhoeven @ 2019-09-19 8:58 UTC (permalink / raw) To: Jani Nikula Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List Hi Jani, On Thu, Sep 19, 2019 at 10:49 AM Jani Nikula <jani.nikula@intel.com> wrote: > On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote: > >> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: > >> When I sent a patch, I use get_maintainer.pl then I add whoever the > >> wrote the commit from the Fixes tag. Then I remove Colin King and Kees > >> Cook from the CC list because they worked all over the tree and I know > >> them. I also normally remove LKML if there is another mailing list but > >> at least one subsystem uses LKML for patchwork so this isn't safe. > >> > >> So the safest instructions are "Use get_matainer.pl and add the person > >> who wrote the commit in the Fixes tag". > > > > Better: perhaps get_maintainer.pl can be taught to add the author of the > > commit pointed to by the Fixes tag, if present? > > The drm maintainer tools [1] have that, with Cc's and reviewers picked > up, and appropriate Cc: stable added. On a random commit from v5.3: Thanks, but that's not scripts/get_maintainer.pl, and restricted to one out of N subsystems. Not so dissimilar from what Dan was complaining about. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-19 8:58 ` Geert Uytterhoeven @ 2019-09-19 9:52 ` Jani Nikula 0 siblings, 0 replies; 82+ messages in thread From: Jani Nikula @ 2019-09-19 9:52 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Jani, > > On Thu, Sep 19, 2019 at 10:49 AM Jani Nikula <jani.nikula@intel.com> wrote: >> On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote: >> > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote: >> >> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: >> >> When I sent a patch, I use get_maintainer.pl then I add whoever the >> >> wrote the commit from the Fixes tag. Then I remove Colin King and Kees >> >> Cook from the CC list because they worked all over the tree and I know >> >> them. I also normally remove LKML if there is another mailing list but >> >> at least one subsystem uses LKML for patchwork so this isn't safe. >> >> >> >> So the safest instructions are "Use get_matainer.pl and add the person >> >> who wrote the commit in the Fixes tag". >> > >> > Better: perhaps get_maintainer.pl can be taught to add the author of the >> > commit pointed to by the Fixes tag, if present? >> >> The drm maintainer tools [1] have that, with Cc's and reviewers picked >> up, and appropriate Cc: stable added. On a random commit from v5.3: > > Thanks, but that's not scripts/get_maintainer.pl, and restricted to one out > of N subsystems. Not so dissimilar from what Dan was complaining about. The point was, perhaps poorly conveyed, to provide it as a reference, and something to steal from. You can think of it as a wrapper around get_maintainer.pl, it's really not subsystem specific, though part of our scripts, and it'll take you all of five minutes to make it generic from the source (MIT): function dim_cite { local sha1 sha1=${1:?$usage} git --git-dir="$DIM_PREFIX/$DIM_REPO/.git" log -1 $sha1 \ "--pretty=format:%H (\"%s\")%n" | \ sed -e 's/\([0-f]\{12\}\)[0-f]*/\1/' } function dim_fixes { local sha1 tag sha1=${1:?$usage} cd $DIM_PREFIX/$DIM_REPO echo "Fixes: $(dim_cite $sha1)" ( git show --no-patch $sha1 | \ sed -e 's/\(Reviewed\|Acked\|Reported\|Signed\)[a-zA-Z-]*-by:/Cc:/' | \ sed -e 's/^ C[Cc]: */Cc: /' | grep '^Cc: ' git show $sha1 | scripts/get_maintainer.pl --email --norolestats --pattern-depth 1 | sed -e "s/^/Cc: /" ) | awk '!x[$0]++' tag=$(git tag --contains $sha1 | grep ^v | sort -V | head -n 1) if [[ -n "$tag" ]]; then if ! echo "$tag" | grep -q -e "-rc"; then echo "Cc: <stable@vger.kernel.org> # ${tag}+" fi fi } HTH, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-19 7:22 ` Geert Uytterhoeven 2019-09-19 8:49 ` Jani Nikula @ 2019-09-20 14:53 ` Laurent Pinchart 2019-09-20 14:59 ` Doug Anderson 1 sibling, 1 reply; 82+ messages in thread From: Laurent Pinchart @ 2019-09-20 14:53 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List On Thu, Sep 19, 2019 at 09:22:45AM +0200, Geert Uytterhoeven wrote: > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: > > > > > +Patches for the media subsystem should be sent to the media mailing list > > > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > > > +HTML will be automatically rejected by the mail server. There's no need > > > > > +to copy the maintainer or sub-maintainer(s). > > > > > > > > There's too much traffic on mailing lists for me to follow everything, I > > > > much prefer being CC'ed on patches. > > > > > > Well, by using patchwork, the best is to take a look on it at least for > > > the patches that you're interested. You could script something using > > > pwclient in order to make it easier. > > > > > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > > > I prefer not to be c/c, as this is just more noise, as I just rely on > > > patchwork for media patches. What about changing this to: > > > > > > Patches for the media subsystem should be sent to the media mailing list > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > HTML will be automatically rejected by the mail server. It could be wise > > > to also copy the sub-maintainer(s). > > > > The documentation should say "Use get_maintainer.pl" and do what it > > says. Everything else is too complicated. > > +1 > > > When I sent a patch, I use get_maintainer.pl then I add whoever the > > wrote the commit from the Fixes tag. Then I remove Colin King and Kees > > Cook from the CC list because they worked all over the tree and I know > > them. I also normally remove LKML if there is another mailing list but > > at least one subsystem uses LKML for patchwork so this isn't safe. > > > > So the safest instructions are "Use get_matainer.pl and add the person > > who wrote the commit in the Fixes tag". > > Better: perhaps get_maintainer.pl can be taught to add the author of the > commit pointed to by the Fixes tag, if present? And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up get_maintainer.pl a bit is a good idea. I'm for instance not sure adding LKML automatically is a good idea if other mailing lists are already CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it when no other mailing list is appropriate certainly makes sense). -- Regards, Laurent Pinchart _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-20 14:53 ` Laurent Pinchart @ 2019-09-20 14:59 ` Doug Anderson 2019-09-21 8:56 ` Jani Nikula 0 siblings, 1 reply; 82+ messages in thread From: Doug Anderson @ 2019-09-20 14:59 UTC (permalink / raw) To: Laurent Pinchart Cc: Mauro Carvalho Chehab, Dan Carpenter, ksummit, Linux Media Mailing List Hi, On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > On Thu, Sep 19, 2019 at 09:22:45AM +0200, Geert Uytterhoeven wrote: > > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > > On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: > > > > > > +Patches for the media subsystem should be sent to the media mailing list > > > > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > > > > +HTML will be automatically rejected by the mail server. There's no need > > > > > > +to copy the maintainer or sub-maintainer(s). > > > > > > > > > > There's too much traffic on mailing lists for me to follow everything, I > > > > > much prefer being CC'ed on patches. > > > > > > > > Well, by using patchwork, the best is to take a look on it at least for > > > > the patches that you're interested. You could script something using > > > > pwclient in order to make it easier. > > > > > > > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > > > > I prefer not to be c/c, as this is just more noise, as I just rely on > > > > patchwork for media patches. What about changing this to: > > > > > > > > Patches for the media subsystem should be sent to the media mailing list > > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > > HTML will be automatically rejected by the mail server. It could be wise > > > > to also copy the sub-maintainer(s). > > > > > > The documentation should say "Use get_maintainer.pl" and do what it > > > says. Everything else is too complicated. > > > > +1 > > > > > When I sent a patch, I use get_maintainer.pl then I add whoever the > > > wrote the commit from the Fixes tag. Then I remove Colin King and Kees > > > Cook from the CC list because they worked all over the tree and I know > > > them. I also normally remove LKML if there is another mailing list but > > > at least one subsystem uses LKML for patchwork so this isn't safe. > > > > > > So the safest instructions are "Use get_matainer.pl and add the person > > > who wrote the commit in the Fixes tag". > > > > Better: perhaps get_maintainer.pl can be taught to add the author of the > > commit pointed to by the Fixes tag, if present? > > And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up > get_maintainer.pl a bit is a good idea. I'm for instance not sure adding > LKML automatically is a good idea if other mailing lists are already > CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it > when no other mailing list is appropriate certainly makes sense). Please don't do this, as it means the patch won't be findable on the "LKML" patchwork instance at: https://lore.kernel.org/patchwork/project/lkml/list/ Having LKML copied on all patches is also nice because it makes it easier to respond to a patch that was posted to a list you didn't subscribe to. I subscribe to LKML and have it redirected to a folder that I never look at. Then if I want to find an email thread I can search that folder and easily respond from within my normal email client. Is there any downside to CCing LKML? -Doug _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-20 14:59 ` Doug Anderson @ 2019-09-21 8:56 ` Jani Nikula 2019-09-23 15:58 ` Doug Anderson 0 siblings, 1 reply; 82+ messages in thread From: Jani Nikula @ 2019-09-21 8:56 UTC (permalink / raw) To: Doug Anderson, Laurent Pinchart Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List On Fri, 20 Sep 2019, Doug Anderson <dianders@chromium.org> wrote: > On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >> And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up >> get_maintainer.pl a bit is a good idea. I'm for instance not sure adding >> LKML automatically is a good idea if other mailing lists are already >> CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it >> when no other mailing list is appropriate certainly makes sense). > > Please don't do this, as it means the patch won't be findable on the > "LKML" patchwork instance at: > > https://lore.kernel.org/patchwork/project/lkml/list/ > > Having LKML copied on all patches is also nice because it makes it > easier to respond to a patch that was posted to a list you didn't > subscribe to. I subscribe to LKML and have it redirected to a folder > that I never look at. Then if I want to find an email thread I can > search that folder and easily respond from within my normal email > client. > > Is there any downside to CCing LKML? I think the question becomes, do we want *everything* posted to LKML? For example, based on the last 30 days, the kernel the monthly addition to LKML traffic from my corner of the kernel would be in this ballpark: $ notmuch count date:30d.. to:intel-gfx@lists.freedesktop.org or to:dri-devel@lists.freedesktop.org and not to linux-kernel@vger.kernel.org and subject:PATCH 96904 OTOH LKML is already a firehose that's impossible to drink from, so not much difference there... BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-21 8:56 ` Jani Nikula @ 2019-09-23 15:58 ` Doug Anderson 2019-09-23 16:04 ` Jonathan Corbet 0 siblings, 1 reply; 82+ messages in thread From: Doug Anderson @ 2019-09-23 15:58 UTC (permalink / raw) To: Jani Nikula Cc: ksummit, Mauro Carvalho Chehab, Dan Carpenter, Linux Media Mailing List Hi, On Sat, Sep 21, 2019 at 1:56 AM Jani Nikula <jani.nikula@intel.com> wrote: > > On Fri, 20 Sep 2019, Doug Anderson <dianders@chromium.org> wrote: > > On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > >> And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up > >> get_maintainer.pl a bit is a good idea. I'm for instance not sure adding > >> LKML automatically is a good idea if other mailing lists are already > >> CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it > >> when no other mailing list is appropriate certainly makes sense). > > > > Please don't do this, as it means the patch won't be findable on the > > "LKML" patchwork instance at: > > > > https://lore.kernel.org/patchwork/project/lkml/list/ > > > > Having LKML copied on all patches is also nice because it makes it > > easier to respond to a patch that was posted to a list you didn't > > subscribe to. I subscribe to LKML and have it redirected to a folder > > that I never look at. Then if I want to find an email thread I can > > search that folder and easily respond from within my normal email > > client. > > > > Is there any downside to CCing LKML? > > I think the question becomes, do we want *everything* posted to LKML? I swear that I was involved in a conversation in the past where someone suggested to stop CCing LKML on patches and Jonathan Corbet jumped in and said that he supported CCing LKML on all patches. I searched for that conversation and couldn't find it, so it's possible I dreamed it. Maybe he can confirm? > For example, based on the last 30 days, the kernel the monthly addition > to LKML traffic from my corner of the kernel would be in this ballpark: > > $ notmuch count date:30d.. to:intel-gfx@lists.freedesktop.org or to:dri-devel@lists.freedesktop.org and not to linux-kernel@vger.kernel.org and subject:PATCH > 96904 > > OTOH LKML is already a firehose that's impossible to drink from, so not > much difference there... Right. At this point I think LKML is just useful as a dumping ground and not a place to look for patches or conversations without filters. It feels fine to keep using it that way. Having another list (like ksummit-discuss) for conversations with a higher signal-to-noise ratio seems like a fine way forward to me. -Doug _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-23 15:58 ` Doug Anderson @ 2019-09-23 16:04 ` Jonathan Corbet 0 siblings, 0 replies; 82+ messages in thread From: Jonathan Corbet @ 2019-09-23 16:04 UTC (permalink / raw) To: Doug Anderson Cc: ksummit, Mauro Carvalho Chehab, Dan Carpenter, Linux Media Mailing List On Mon, 23 Sep 2019 08:58:28 -0700 Doug Anderson <dianders@chromium.org> wrote: > I swear that I was involved in a conversation in the past where > someone suggested to stop CCing LKML on patches and Jonathan Corbet > jumped in and said that he supported CCing LKML on all patches. I don't *think* I said that, I have no particular reason to argue for doing that...? There are people out there who feel that absolutely everything needs to be on LKML, but I don't really have a strong opinion on that matter. jon _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-19 6:56 ` Dan Carpenter 2019-09-19 7:22 ` Geert Uytterhoeven @ 2019-09-19 9:52 ` Mauro Carvalho Chehab 2019-09-25 17:13 ` Joe Perches 2 siblings, 0 replies; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-19 9:52 UTC (permalink / raw) To: Dan Carpenter; +Cc: ksummit-discuss, Linux Media Mailing List Em Thu, 19 Sep 2019 09:56:44 +0300 Dan Carpenter <dan.carpenter@oracle.com> escreveu: > On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote: > > > > +Patches for the media subsystem should be sent to the media mailing list > > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > > > +HTML will be automatically rejected by the mail server. There's no need > > > > +to copy the maintainer or sub-maintainer(s). > > > > > > There's too much traffic on mailing lists for me to follow everything, I > > > much prefer being CC'ed on patches. > > > > Well, by using patchwork, the best is to take a look on it at least for > > the patches that you're interested. You could script something using > > pwclient in order to make it easier. > > > > Anyway, not sure if the other sub-maintainers see the same way. From my side, > > I prefer not to be c/c, as this is just more noise, as I just rely on > > patchwork for media patches. What about changing this to: > > > > Patches for the media subsystem should be sent to the media mailing list > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > HTML will be automatically rejected by the mail server. It could be wise > > to also copy the sub-maintainer(s). > > The documentation should say "Use get_maintainer.pl" and do what it > says. Everything else is too complicated. Works for me. > Occasionally staging maintainers will complain that they aren't CC'd > even though the staging/driver/README says to CC them and I am tell them > "No, the responsibility is for you to add yourself to MAINTAINERS. It > doesn't matter what the documentation says, you messed up so you need to > stop getting annoyed with newbies for not reading the documentation when > it's your fault you weren't CC'd." > > When I sent a patch, I use get_maintainer.pl then I add whoever the > wrote the commit from the Fixes tag. Then I remove Colin King and Kees > Cook from the CC list because they worked all over the tree and I know > them. I also normally remove LKML if there is another mailing list but > at least one subsystem uses LKML for patchwork so this isn't safe. I use get_maintainer.pl myself, but when submitting some patches (like documentation ones), I need to manually clean the list, as it is not uncommon to have a really long c/c list. > > So the safest instructions are "Use get_matainer.pl and add the person > who wrote the commit in the Fixes tag". > > regards, > dan carpenter > > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-19 6:56 ` Dan Carpenter 2019-09-19 7:22 ` Geert Uytterhoeven 2019-09-19 9:52 ` Mauro Carvalho Chehab @ 2019-09-25 17:13 ` Joe Perches 2019-09-25 18:40 ` Kees Cook 2019-09-26 10:25 ` Geert Uytterhoeven 2 siblings, 2 replies; 82+ messages in thread From: Joe Perches @ 2019-09-25 17:13 UTC (permalink / raw) To: Dan Carpenter, Mauro Carvalho Chehab Cc: ksummit-discuss, Linux Media Mailing List On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote: > When I sent a patch, I use get_maintainer.pl then I add whoever the > wrote the commit from the Fixes tag. Then I remove Colin King and Kees > Cook from the CC list because they worked all over the tree and I know > them. I also normally remove LKML if there is another mailing list but > at least one subsystem uses LKML for patchwork so this isn't safe. > > So the safest instructions are "Use get_matainer.pl and add the person > who wrote the commit in the Fixes tag". Maybe add this: Add the signers of any commit referenced in a "Fixes: <commit>" line of a patch description. --- scripts/get_maintainer.pl | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl index 5ef59214c555..34085d146fa2 100755 --- a/scripts/get_maintainer.pl +++ b/scripts/get_maintainer.pl @@ -26,6 +26,7 @@ my $email = 1; my $email_usename = 1; my $email_maintainer = 1; my $email_reviewer = 1; +my $email_fixes = 1; my $email_list = 1; my $email_moderated_list = 1; my $email_subscriber_list = 0; @@ -249,6 +250,7 @@ if (!GetOptions( 'r!' => \$email_reviewer, 'n!' => \$email_usename, 'l!' => \$email_list, + 'fixes!' => \$email_fixes, 'moderated!' => \$email_moderated_list, 's!' => \$email_subscriber_list, 'multiline!' => \$output_multiline, @@ -503,6 +505,7 @@ sub read_mailmap { ## use the filenames on the command line or find the filenames in the patchfiles my @files = (); +my @fixes = (); # If a patch description includes Fixes: lines my @range = (); my @keyword_tvi = (); my @file_emails = (); @@ -568,6 +571,8 @@ foreach my $file (@ARGV) { my $filename2 = $2; push(@files, $filename1); push(@files, $filename2); + } elsif (m/^Fixes:\s+([0-9a-fA-F]{6,40})/) { + push(@fixes, $1) if ($email_fixes); } elsif (m/^\+\+\+\s+(\S+)/ or m/^---\s+(\S+)/) { my $filename = $1; $filename =~ s@^[^/]*/@@; @@ -598,6 +603,7 @@ foreach my $file (@ARGV) { } @file_emails = uniq(@file_emails); +@fixes = uniq(@fixes); my %email_hash_name; my %email_hash_address; @@ -612,7 +618,6 @@ my %deduplicate_name_hash = (); my %deduplicate_address_hash = (); my @maintainers = get_maintainers(); - if (@maintainers) { @maintainers = merge_email(@maintainers); output(@maintainers); @@ -927,6 +932,10 @@ sub get_maintainers { } } + foreach my $fix (@fixes) { + vcs_add_commit_signers($fix, "blamed_fixes"); + } + foreach my $email (@email_to, @list_to) { $email->[0] = deduplicate_email($email->[0]); } @@ -1031,6 +1040,7 @@ MAINTAINER field selection options: --roles => show roles (status:subsystem, git-signer, list, etc...) --rolestats => show roles and statistics (commits/total_commits, %) --file-emails => add email addresses found in -f file (default: 0 (off)) + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on)) --scm => print SCM tree(s) if any --status => print status if any --subsystem => print subsystem name if any @@ -1730,6 +1740,32 @@ sub vcs_is_hg { return $vcs_used == 2; } +sub vcs_add_commit_signers { + return if (!vcs_exists()); + + my ($commit, $desc) = @_; + my $commit_count = 0; + my $commit_authors_ref; + my $commit_signers_ref; + my $stats_ref; + my @commit_authors = (); + my @commit_signers = (); + my $cmd; + + $cmd = $VCS_cmds{"find_commit_signers_cmd"}; + $cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd + + ($commit_count, $commit_signers_ref, $commit_authors_ref, $stats_ref) = vcs_find_signers($cmd, ""); + @commit_authors = @{$commit_authors_ref} if defined $commit_authors_ref; + @commit_signers = @{$commit_signers_ref} if defined $commit_signers_ref; + + foreach my $signer (@commit_signers) { + $signer = deduplicate_email($signer); + } + + vcs_assign($desc, 1, @commit_signers); +} + sub interactive_get_maintainers { my ($list_ref) = @_; my @list = @$list_ref; _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-25 17:13 ` Joe Perches @ 2019-09-25 18:40 ` Kees Cook 2019-09-26 15:14 ` Joe Perches 2019-09-26 10:25 ` Geert Uytterhoeven 1 sibling, 1 reply; 82+ messages in thread From: Kees Cook @ 2019-09-25 18:40 UTC (permalink / raw) To: Joe Perches Cc: Mauro Carvalho Chehab, ksummit-discuss, Dan Carpenter, Linux Media Mailing List On Wed, Sep 25, 2019 at 10:13:37AM -0700, Joe Perches wrote: > On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote: > > When I sent a patch, I use get_maintainer.pl then I add whoever the > > wrote the commit from the Fixes tag. Then I remove Colin King and Kees > > Cook from the CC list because they worked all over the tree and I know > > them. I also normally remove LKML if there is another mailing list but > > at least one subsystem uses LKML for patchwork so this isn't safe. > > > > So the safest instructions are "Use get_matainer.pl and add the person > > who wrote the commit in the Fixes tag". > > Maybe add this: > > Add the signers of any commit referenced in a "Fixes: <commit>" line > of a patch description. Oh yes please! I've always done this manually, so that's a nice bit of automation. :) > > --- > scripts/get_maintainer.pl | 38 +++++++++++++++++++++++++++++++++++++- > 1 file changed, 37 insertions(+), 1 deletion(-) > > diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl > index 5ef59214c555..34085d146fa2 100755 > --- a/scripts/get_maintainer.pl > +++ b/scripts/get_maintainer.pl > @@ -26,6 +26,7 @@ my $email = 1; > my $email_usename = 1; > my $email_maintainer = 1; > my $email_reviewer = 1; > +my $email_fixes = 1; > my $email_list = 1; > my $email_moderated_list = 1; > my $email_subscriber_list = 0; > @@ -249,6 +250,7 @@ if (!GetOptions( > 'r!' => \$email_reviewer, > 'n!' => \$email_usename, > 'l!' => \$email_list, > + 'fixes!' => \$email_fixes, > 'moderated!' => \$email_moderated_list, > 's!' => \$email_subscriber_list, > 'multiline!' => \$output_multiline, > @@ -503,6 +505,7 @@ sub read_mailmap { > ## use the filenames on the command line or find the filenames in the patchfiles > > my @files = (); > +my @fixes = (); # If a patch description includes Fixes: lines > my @range = (); > my @keyword_tvi = (); > my @file_emails = (); > @@ -568,6 +571,8 @@ foreach my $file (@ARGV) { > my $filename2 = $2; > push(@files, $filename1); > push(@files, $filename2); > + } elsif (m/^Fixes:\s+([0-9a-fA-F]{6,40})/) { Is "6" a safe lower bound here? I thought 12 was the way to go? $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail 238 8 300 7 330 14 344 6 352 11 408 40 425 10 735 16 1866 13 31446 12 Hmpf, 6 is pretty high up there... > + push(@fixes, $1) if ($email_fixes); > } elsif (m/^\+\+\+\s+(\S+)/ or m/^---\s+(\S+)/) { > my $filename = $1; > $filename =~ s@^[^/]*/@@; > @@ -598,6 +603,7 @@ foreach my $file (@ARGV) { > } > > @file_emails = uniq(@file_emails); > +@fixes = uniq(@fixes); > > my %email_hash_name; > my %email_hash_address; > @@ -612,7 +618,6 @@ my %deduplicate_name_hash = (); > my %deduplicate_address_hash = (); > > my @maintainers = get_maintainers(); > - > if (@maintainers) { > @maintainers = merge_email(@maintainers); > output(@maintainers); > @@ -927,6 +932,10 @@ sub get_maintainers { > } > } > > + foreach my $fix (@fixes) { > + vcs_add_commit_signers($fix, "blamed_fixes"); > + } > + > foreach my $email (@email_to, @list_to) { > $email->[0] = deduplicate_email($email->[0]); > } > @@ -1031,6 +1040,7 @@ MAINTAINER field selection options: > --roles => show roles (status:subsystem, git-signer, list, etc...) > --rolestats => show roles and statistics (commits/total_commits, %) > --file-emails => add email addresses found in -f file (default: 0 (off)) > + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on)) Should "Tested-by" and "Co-developed-by" get added to @signature_tags ? > --scm => print SCM tree(s) if any > --status => print status if any > --subsystem => print subsystem name if any > @@ -1730,6 +1740,32 @@ sub vcs_is_hg { > return $vcs_used == 2; > } > > +sub vcs_add_commit_signers { > + return if (!vcs_exists()); > + > + my ($commit, $desc) = @_; > + my $commit_count = 0; > + my $commit_authors_ref; > + my $commit_signers_ref; > + my $stats_ref; > + my @commit_authors = (); > + my @commit_signers = (); > + my $cmd; > + > + $cmd = $VCS_cmds{"find_commit_signers_cmd"}; > + $cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd > + > + ($commit_count, $commit_signers_ref, $commit_authors_ref, $stats_ref) = vcs_find_signers($cmd, ""); > + @commit_authors = @{$commit_authors_ref} if defined $commit_authors_ref; > + @commit_signers = @{$commit_signers_ref} if defined $commit_signers_ref; > + > + foreach my $signer (@commit_signers) { > + $signer = deduplicate_email($signer); > + } > + > + vcs_assign($desc, 1, @commit_signers); > +} @commit_authors is unused? > + > sub interactive_get_maintainers { > my ($list_ref) = @_; > my @list = @$list_ref; > > > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss Yay! :) -- Kees Cook _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-25 18:40 ` Kees Cook @ 2019-09-26 15:14 ` Joe Perches 2019-09-26 15:53 ` Kees Cook 0 siblings, 1 reply; 82+ messages in thread From: Joe Perches @ 2019-09-26 15:14 UTC (permalink / raw) To: Kees Cook Cc: Mauro Carvalho Chehab, ksummit-discuss, Dan Carpenter, Linux Media Mailing List On Wed, 2019-09-25 at 11:40 -0700, Kees Cook wrote: > On Wed, Sep 25, 2019 at 10:13:37AM -0700, Joe Perches wrote: > > On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote: > > > When I sent a patch, I use get_maintainer.pl then I add whoever the > > > wrote the commit from the Fixes tag. Then I remove Colin King and Kees > > > Cook from the CC list because they worked all over the tree and I know > > > them. I also normally remove LKML if there is another mailing list but > > > at least one subsystem uses LKML for patchwork so this isn't safe. > > > > > > So the safest instructions are "Use get_matainer.pl and add the person > > > who wrote the commit in the Fixes tag". > > > > Maybe add this: > > > > Add the signers of any commit referenced in a "Fixes: <commit>" line > > of a patch description. > > Oh yes please! I've always done this manually, so that's a nice bit of > automation. :) > > Is "6" a safe lower bound here? I thought 12 was the way to go? [] > $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail > 238 8 > 300 7 > 330 14 > 344 6 > 352 11 > 408 40 > 425 10 > 735 16 > 1866 13 > 31446 12 > > Hmpf, 6 is pretty high up there... Yes, but your grep then col2 isn't right. You are counting all the 'Fixes: commit <foo>' output as 6 because that's the length of 'commit'. I also think the length of the hex commit value doesn't matter much as it's got to be a specific single commit SHA1 anyway, otherwise the commit id lookup will fail. > > > @@ -1031,6 +1040,7 @@ MAINTAINER field selection options: > > --roles => show roles (status:subsystem, git-signer, list, etc...) > > --rolestats => show roles and statistics (commits/total_commits, %) > > --file-emails => add email addresses found in -f file (default: 0 (off)) > > + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on)) > > Should "Tested-by" and "Co-developed-by" get added to @signature_tags ? All "<foo>-by:" signatures are added. > @commit_authors is unused? Yes, authors are already required to sign-off so it's just duplicating already existing signatures. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-26 15:14 ` Joe Perches @ 2019-09-26 15:53 ` Kees Cook 2019-09-26 16:02 ` Joe Perches 0 siblings, 1 reply; 82+ messages in thread From: Kees Cook @ 2019-09-26 15:53 UTC (permalink / raw) To: Joe Perches Cc: Mauro Carvalho Chehab, ksummit-discuss, Dan Carpenter, Linux Media Mailing List On Thu, Sep 26, 2019 at 08:14:03AM -0700, Joe Perches wrote: > On Wed, 2019-09-25 at 11:40 -0700, Kees Cook wrote: > > Is "6" a safe lower bound here? I thought 12 was the way to go? > [] > > $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail > > 238 8 > > 300 7 > > 330 14 > > 344 6 > > 352 11 > > 408 40 > > 425 10 > > 735 16 > > 1866 13 > > 31446 12 > > > > Hmpf, 6 is pretty high up there... > > Yes, but your grep then col2 isn't right. > You are counting all the 'Fixes: commit <foo>' output > as 6 because that's the length of 'commit'. the [a-f0-9]{1,40} already excludes "commit". > I also think the length of the hex commit value doesn't > matter much as it's got to be a specific single commit > SHA1 anyway, otherwise the commit id lookup will fail. Fail enough. We do already have 6-digit SHA1 collisions, so it seemed like using more than 6 would be nicer? *shrug* I don't have a strong opinion. :) > > > > > @@ -1031,6 +1040,7 @@ MAINTAINER field selection options: > > > --roles => show roles (status:subsystem, git-signer, list, etc...) > > > --rolestats => show roles and statistics (commits/total_commits, %) > > > --file-emails => add email addresses found in -f file (default: 0 (off)) > > > + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on)) > > > > Should "Tested-by" and "Co-developed-by" get added to @signature_tags ? > > All "<foo>-by:" signatures are added. Ah, I'd missed where that happened. I do note that's only when git-all-signature-types is set, which is default 0. (/me goes to add this to his invocations...) my $email_git_all_signature_types = 0; ... if ($email_git_all_signature_types) { $signature_pattern = "(.+?)[Bb][Yy]:"; } else { $signature_pattern = "\(" . join("|", @signature_tags) . "\)"; } > > @commit_authors is unused? > > Yes, authors are already required to sign-off so > it's just duplicating already existing signatures. Sure, it just seemed odd to populate it if it wasn't going to be used. -- Kees Cook _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-26 15:53 ` Kees Cook @ 2019-09-26 16:02 ` Joe Perches 2019-09-26 16:24 ` Kees Cook 0 siblings, 1 reply; 82+ messages in thread From: Joe Perches @ 2019-09-26 16:02 UTC (permalink / raw) To: Kees Cook Cc: Mauro Carvalho Chehab, ksummit-discuss, Dan Carpenter, Linux Media Mailing List On Thu, 2019-09-26 at 08:53 -0700, Kees Cook wrote: > On Thu, Sep 26, 2019 at 08:14:03AM -0700, Joe Perches wrote: > > On Wed, 2019-09-25 at 11:40 -0700, Kees Cook wrote: > > > Is "6" a safe lower bound here? I thought 12 was the way to go? > > [] > > > $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail > > > 238 8 > > > 300 7 > > > 330 14 > > > 344 6 > > > 352 11 > > > 408 40 > > > 425 10 > > > 735 16 > > > 1866 13 > > > 31446 12 > > > > > > Hmpf, 6 is pretty high up there... > > > > Yes, but your grep then col2 isn't right. > > You are counting all the 'Fixes: commit <foo>' output > > as 6 because that's the length of 'commit'. > > the [a-f0-9]{1,40} already excludes "commit". No it doesn't as commit starts with c which matches [a-f0-9]{1,40} Try your original egrep command line yourself. Maybe use: $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | awk '{ if (length($2) == 6) { print $0;} }' The first few matches are the commit referenced in Fixes: below replaced the call to Fixes: commit 18a992787896 ("ARM: ux500: move soc_id driver to drivers/soc") Fixes: commit 0580dde59438 ("ASoC: simple-card-utils: add asoc_simple_debug_info()") Since Fixes: 8c5421c016a4 ("perf pmu: Display pmu name when printing Fixes: commit 961fb3c206dc ("ASoC: rockchip: rk3399_gru_sound: don't select unnecessary Platform") > > I also think the length of the hex commit value doesn't > > matter much as it's got to be a specific single commit > > SHA1 anyway, otherwise the commit id lookup will fail. > > Fail enough. We do already have 6-digit SHA1 collisions, so it seemed > like using more than 6 would be nicer? *shrug* I don't have a strong > opinion. :) > > > > > > @@ -1031,6 +1040,7 @@ MAINTAINER field selection options: > > > > --roles => show roles (status:subsystem, git-signer, list, etc...) > > > > --rolestats => show roles and statistics (commits/total_commits, %) > > > > --file-emails => add email addresses found in -f file (default: 0 (off)) > > > > + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on)) > > > > > > Should "Tested-by" and "Co-developed-by" get added to @signature_tags ? > > > > All "<foo>-by:" signatures are added. > > Ah, I'd missed where that happened. I do note that's only when > git-all-signature-types is set, which is default 0. (/me goes to add > this to his invocations...) > > my $email_git_all_signature_types = 0; > ... > if ($email_git_all_signature_types) { > $signature_pattern = "(.+?)[Bb][Yy]:"; > } else { > $signature_pattern = "\(" . join("|", @signature_tags) . "\)"; > } > > > > @commit_authors is unused? > > > > Yes, authors are already required to sign-off so > > it's just duplicating already existing signatures. > > Sure, it just seemed odd to populate it if it wasn't going to be used. It's a generic function. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-26 16:02 ` Joe Perches @ 2019-09-26 16:24 ` Kees Cook 0 siblings, 0 replies; 82+ messages in thread From: Kees Cook @ 2019-09-26 16:24 UTC (permalink / raw) To: Joe Perches Cc: Mauro Carvalho Chehab, ksummit-discuss, Dan Carpenter, Linux Media Mailing List On Thu, Sep 26, 2019 at 09:02:07AM -0700, Joe Perches wrote: > > the [a-f0-9]{1,40} already excludes "commit". > > No it doesn't as commit starts with c which matches [a-f0-9]{1,40} Whoops! Yes, sorry, you're right. I needed a trailing whitespace in the regex. -- Kees Cook _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation 2019-09-25 17:13 ` Joe Perches 2019-09-25 18:40 ` Kees Cook @ 2019-09-26 10:25 ` Geert Uytterhoeven 1 sibling, 0 replies; 82+ messages in thread From: Geert Uytterhoeven @ 2019-09-26 10:25 UTC (permalink / raw) To: Joe Perches Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List Hi Joe, On Wed, Sep 25, 2019 at 7:32 PM Joe Perches <joe@perches.com> wrote: > On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote: > > When I sent a patch, I use get_maintainer.pl then I add whoever the > > wrote the commit from the Fixes tag. Then I remove Colin King and Kees > > Cook from the CC list because they worked all over the tree and I know > > them. I also normally remove LKML if there is another mailing list but > > at least one subsystem uses LKML for patchwork so this isn't safe. > > > > So the safest instructions are "Use get_matainer.pl and add the person > > who wrote the commit in the Fixes tag". > > Maybe add this: > > Add the signers of any commit referenced in a "Fixes: <commit>" line > of a patch description. > > --- > scripts/get_maintainer.pl | 38 +++++++++++++++++++++++++++++++++++++- > 1 file changed, 37 insertions(+), 1 deletion(-) Thanks! I gave it a quick try for my first fix after returning from ER, and it did the right thing. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* [Ksummit-discuss] [PATCH v2] media: add a subsystem profile documentation 2019-09-18 12:36 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Laurent Pinchart 2019-09-18 13:57 ` Mauro Carvalho Chehab @ 2019-09-18 13:59 ` Mauro Carvalho Chehab [not found] ` <1e479f17-dbc8-b44d-bd1e-4229a6dbf151@collabora.com> 1 sibling, 1 reply; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-18 13:59 UTC (permalink / raw) To: Linux Media Mailing List; +Cc: Mauro Carvalho Chehab, ksummit-discuss Document the basic policies of the media subsystem profile. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> --- Documentation/media/index.rst | 1 + .../media/maintainer-entry-profile.rst | 157 ++++++++++++++++++ MAINTAINERS | 1 + 3 files changed, 159 insertions(+) create mode 100644 Documentation/media/maintainer-entry-profile.rst diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst index 0301c25ff887..ac94685b822a 100644 --- a/Documentation/media/index.rst +++ b/Documentation/media/index.rst @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation .. toctree:: :maxdepth: 2 + maintainer-entry-profile media_uapi media_kapi dvb-drivers/index diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst new file mode 100644 index 000000000000..68d642abe2c1 --- /dev/null +++ b/Documentation/media/maintainer-entry-profile.rst @@ -0,0 +1,157 @@ +Media Subsystem Profile +======================= + +Overview +-------- + +The media subsystem covers support for a variety of devices: stream +capture, analog and digital TV, cameras, remote controllers, HDMI CEC +and media pipeline control. + +It covers, mainly, the contents of those directories: + + - drivers/media + - drivers/staging/media + - Documentation/media + - include/media + +Both media userspace and Kernel APIs are documented and should be kept in +sync with the API changes. It means that all patches that add new +features to the subsystem should also bring changes to the corresponding +API files. + +Also, patches that changes the Open Firmware/Device Tree bindings should +also be reviewed by the Device Tree maintainers. + +Due to the size and wide scope of the media subsystem, media's +maintainership model is to have sub-maintainers that have a broad +knowledge of an specific aspect of the subsystem. It is a +sub-maintainer's task to review the patches, providing feedback to users +if the patches are following the subsystem rules and are properly using +the media internal and external APIs. + +Patches for the media subsystem should be sent to the media mailing list +at linux-media@vger.kernel.org as plain text only e-mail. Emails with +HTML will be automatically rejected by the mail server. It could be wise +to also copy the sub-maintainer(s). + +Media's workflow is heavily based on Patchwork, meaning that, once a patch +is submitted, it should appear at: + + - https://patchwork.linuxtv.org/project/linux-media/list/ + +If it doesn't automatically appear there after a few minutes, then +probably something got wrong on your submission. Please check if the +email is in plain text only and if your emailer is not mangling with +whitespaces before complaining or submit it again. + +Sub-maintainers ++++++++++++++++ + +At the media subsystem, we have a group of experienced developers that +are responsible for doing the code reviews at the drivers (called +sub-maintainers), and another senior developer responsible for the +subsystem as a hole. For core changes, whenever possible, multiple +media (sub-)maintainers do the review. + +The sub-maintainers work on specific areas of the subsystem, as +described below: + +Digital TV: + Sean Young <sean@mess.org> + +HDMI CEC: + Hans Verkuil <hverkuil@xs4all.nl> + +Media controller drivers: + Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +Remote Controllers: + Sean Young <sean@mess.org> + +Sensor drivers: + Sakari Ailus <sakari.ailus@linux.intel.com> + +V4L2 drivers: + Hans Verkuil <hverkuil@xs4all.nl> + +Submit Checklist Addendum +------------------------- + +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ +that should be used in order to check if the drivers are properly +implementing the media APIs. + +Those tests need to pass before the patches go upstream. + +Also, please notice that we build the Kernel with:: + + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script + +Where the check script is:: + + #!/bin/bash + /devel/smatch/smatch -p=kernel $@ >&2 + /devel/sparse/sparse $@ >&2 + +Be sure to not introduce new warnings on your patches without a +very good reason. + +Key Cycle Dates +--------------- + +New submissions can be sent at any time, but if they intend to hit the +next merge window they should be sent before -rc5, and ideally stabilized +in the linux-media branch by -rc6. + +Coding Style Addendum +--------------------- + +Media development uses checkpatch on strict mode to verify the code style, e. g.:: + + $ ./script/checkpatch.pl --strict + +Please notice that the goal here is to improve code readability. On a few +cases, checkpatch may actually point to something that would look worse. + +So, you should use good send sense here, being prepared to justify any +coding style decision. + +Please also notice that, on some cases, when you fix one issue, you may +receive warnings about lines longer than 80 columns. It is fine to have +longer lines if this means that other warnings will be fixed by that. + +Yet, if you're having more than 80 columns on a line, please consider +simplifying the code - if too idented - or to use shorter names for +variables. + +Review Cadence +-------------- + +Provided that your patch is at https://patchwork.linuxtv.org, it should +be sooner or later handled, so you don't need to re-submit a patch. + +Except for bug fixes, we don't usually add new patches to the development +tree between -rc6 and the next -rc1. + +Please notice that the media subsystem is a high traffic one, so it +could take a while for us to be able to review your patches. Feel free +to ping if you don't get a feedback in a couple of weeks or to ask +other developers to publicly add Reviewed-by and, more importantly, +Tested-by tags. + +Please note that we expect a detailed description for Tested-by, +identifying what boards were used at the test and what it was tested. + +Style Cleanup Patches +--------------------- + +Style-cleanups are welcome when they come together with other changes +at the files where the style changes will affect. + +We may accept pure standalone style-cleanups, but they should ideally +be one patch for the hole subsystem (if the cleanup is low volume), +or at least be grouped per directory. So, for example, if you're doing +big cleanup changes at drivers under drivers/media, please send a single +patch for all drivers under drivers/media/pci, another one for +drivers/media/usb and so on. diff --git a/MAINTAINERS b/MAINTAINERS index 7c62b45201d7..e7f44ec05a42 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10077,6 +10077,7 @@ W: https://linuxtv.org Q: http://patchwork.kernel.org/project/linux-media/list/ T: git git://linuxtv.org/media_tree.git S: Maintained +P: Documentation/media/maintainer-entry-profile.rst F: Documentation/devicetree/bindings/media/ F: Documentation/media/ F: drivers/media/ -- 2.21.0 _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply related [flat|nested] 82+ messages in thread
[parent not found: <1e479f17-dbc8-b44d-bd1e-4229a6dbf151@collabora.com>]
* Re: [Ksummit-discuss] [PATCH v2] media: add a subsystem profile documentation [not found] ` <1e479f17-dbc8-b44d-bd1e-4229a6dbf151@collabora.com> @ 2019-09-18 14:11 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-18 14:11 UTC (permalink / raw) To: André Almeida; +Cc: ksummit-discuss, Linux Media Mailing List Em Wed, 18 Sep 2019 11:07:16 -0300 André Almeida <andrealmeid@collabora.com> escreveu: > Hello Mauro, > > On 9/18/19 10:59 AM, Mauro Carvalho Chehab wrote: > > Document the basic policies of the media subsystem profile. > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> > > --- > > Documentation/media/index.rst | 1 + > > .../media/maintainer-entry-profile.rst | 157 ++++++++++++++++++ > > MAINTAINERS | 1 + > > 3 files changed, 159 insertions(+) > > create mode 100644 Documentation/media/maintainer-entry-profile.rst > > > > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst > > index 0301c25ff887..ac94685b822a 100644 > > --- a/Documentation/media/index.rst > > +++ b/Documentation/media/index.rst > > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation > > .. toctree:: > > :maxdepth: 2 > > > > + maintainer-entry-profile > > media_uapi > > media_kapi > > dvb-drivers/index > > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst > > new file mode 100644 > > index 000000000000..68d642abe2c1 > > --- /dev/null > > +++ b/Documentation/media/maintainer-entry-profile.rst > > @@ -0,0 +1,157 @@ > > +Media Subsystem Profile > > +======================= > > + > > +Overview > > +-------- > > + > > +The media subsystem covers support for a variety of devices: stream > > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC > > +and media pipeline control. > > + > > +It covers, mainly, the contents of those directories: > > + > > + - drivers/media > > + - drivers/staging/media > > + - Documentation/media > > + - include/media > > + > > +Both media userspace and Kernel APIs are documented and should be kept in > > +sync with the API changes. It means that all patches that add new > > +features to the subsystem should also bring changes to the corresponding > > +API files. > > + > > +Also, patches that changes the Open Firmware/Device Tree bindings should > > +also be reviewed by the Device Tree maintainers. > > + > > +Due to the size and wide scope of the media subsystem, media's > > +maintainership model is to have sub-maintainers that have a broad > > +knowledge of an specific aspect of the subsystem. It is a > > +sub-maintainer's task to review the patches, providing feedback to users > > +if the patches are following the subsystem rules and are properly using > > +the media internal and external APIs. > > + > > +Patches for the media subsystem should be sent to the media mailing list > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with > > +HTML will be automatically rejected by the mail server. It could be wise > > +to also copy the sub-maintainer(s). > > + > > +Media's workflow is heavily based on Patchwork, meaning that, once a patch > > +is submitted, it should appear at: > > + > > + - https://patchwork.linuxtv.org/project/linux-media/list/ > > + > > +If it doesn't automatically appear there after a few minutes, then > > +probably something got wrong on your submission. Please check if the > > +email is in plain text only and if your emailer is not mangling with > > +whitespaces before complaining or submit it again. > > + > > +Sub-maintainers > > ++++++++++++++++ > > What is the motivation for using "+++" instead of "---"? Just cosmetics. This chapter doesn't exist at the original profile, as sub-maintainers, co-maintainers, etc. are used only on a few subsystems. So, I'm adding it as a sub-chapter. Thanks, Mauro _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-11 15:48 [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams ` (2 preceding siblings ...) 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams @ 2019-09-11 16:40 ` Martin K. Petersen 2019-09-12 13:31 ` Bart Van Assche 2019-09-12 13:10 ` Bart Van Assche 4 siblings, 1 reply; 82+ messages in thread From: Martin K. Petersen @ 2019-09-11 16:40 UTC (permalink / raw) To: Dan Williams Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, linux-kernel, Greg Kroah-Hartman, Steve French, Vishal Verma, Mauro Carvalho Chehab, Dmitry Vyukov, Tobin C. Harding 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 <martin.petersen@oracle.com> 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-scsi@vger.kernel.org * Please make sure to Cc: the maintainer of the driver/component you are changing. * 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. * Clearly indicate in the introductory letter which tree your submission is aimed at (scsi-fixes or scsi-queue). For individual patches you can indicate the desired tree below the --- separator. * As a rule of thumb, any patch that goes through the scsi-fixes tree should have a stable tag unless it was a regression introduced in the current release. * If the patch is a bugfix, please add: Fixes: 1234deadbeef ("Implement foobarbaz") Cc: <stable@vger.kernel.org> # v4.x+ Where the v4.x indicates when commit 1234deadbeef was added to the kernel. * When posting a revised patch or series, please manually add any Acked-by:, Reviewed-by:, or Tested-by: tags you may have received. Tags are only valid if the patch has not changed significantly. Rebasing without conflicts and typo fixes are generally OK and do not invalidate tags. * Please CC: everyone that provided feedback when posting a revised patch or series. * Custom patch number formatting often confuses patchwork. Please use git send-email -v instead of manually adding version numbers to individual patches. To send version 3 of a 10 patch series from the tip of the current tree you can do: git send-email -10 -v3 --compose --to=linux-scsi@vger.kernel.org * Please put a change log after a --- separator in each revised patch. If the reason for the repost is global (i.e. a rebase) it is fine to put the changelog in the cover letter. Patch Acceptance Criteria ========================= * A patch needs two positive reviews (non-author Signed-off-by:, Acked-by:, Reviewed-by:, or Tested-by:). * A Tested-by: is worth a thousand reviews. * For drivers, at least one review is required from somebody outside the submitting company. * Nobody has expressed any concerns about the patch on linux-scsi. * The patch must apply cleanly. Use checkpatch and git send-email. * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__") and does not incur any zeroday test robot complaints. * The patch must have a commit message that describes, comprehensively and in plain English, what the patch does. - Do not link to vendor bugzilla entries that require special access credentials. If there is anything of importance in bugzilla, put it in the commit message. - The bigger and more intrusive the patch, the bigger the accompanying commit message needs to be. "fooscsi: Add PCI id for model XYZ" is fine as a one-liner. "fooscsi: Rewrite DMA allocation and queue setup" most likely needs several paragraphs of discussion in the commit message. Patch Review Communities ======================== While core SCSI folks generally perform a cursory review of every patch, it is imperative that contributors with an interest in a particular component form small communities that can review and test each other's code. Such informal communities exist for several components or sub-subsystems underneath the SCSI tree. The best way to facilitate that your patch gets merged is to review patches submitted by your fellow contributors and hope that they return the favor. Patch Reviewer Responsibilities =============================== If you provide feedback to a patch and the patch author addresses your concerns in a new version, you are expected to respond to the new patch. Many code contributions series fail to make forward progress because reviewers do not ack or nack the changes they requested to be made. Please make sure to always follow up when your review comments are being addressed. Driver Maintainer Responsibilities ================================== Many of the actively developed SCSI subsystem drivers have one or more official maintainers. These maintainers are often employed by the company manufacturing the hardware in question and therefore have a vested interest in making sure the driver is working correctly. A driver maintainer must review and respond to *all submitted patches* to the driver in a timely manner (5 business days). This includes: * Proposed functional changes to the driver code * Security fixes * Trivial and typo patches * Changes compelled by kernel interface changes * Patches required to work correctly on architectures not commercially supported by the hardware manufacturer Patch Acceptance Status ======================= * Submitted patches and their current status can be viewed in patchwork at: https://patchwork.kernel.org/project/linux-scsi/list/ * If a submitted patch is not visible in patchwork, it does not exist. Please repost. * If only a portion of a patch series visible in patchwork, the series does not exist. Please repost. * Once a patch has been merged, you will receive a mail indicating into which tree it has been accepted. * Patches that have not received sufficient Acked-by:, Reviewed-by:, or Tested-by: tags after two weeks get moved to "Deferred" status. This indicates that it necessary to resubmit the patches to the linux-scsi list. * Patches submitted to linux-scsi but which need to go through another subsystem tree will be set to "Not Applicable" status. * Patches which require rework will be set to "Changes Requested" status. * Patches which have been obsoleted by a later version will be set to "Superceded" status. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-11 16:40 ` [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen @ 2019-09-12 13:31 ` Bart Van Assche 2019-09-12 15:34 ` Joe Perches 2019-09-13 22:03 ` Martin K. Petersen 0 siblings, 2 replies; 82+ messages in thread From: Bart Van Assche @ 2019-09-12 13:31 UTC (permalink / raw) To: Martin K. Petersen, Dan Williams Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Dmitry Vyukov, Vishal Verma, Mauro Carvalho Chehab, Steve French, Tobin C. Harding 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. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-12 13:31 ` Bart Van Assche @ 2019-09-12 15:34 ` Joe Perches 2019-09-12 20:01 ` Bart Van Assche 2019-09-13 22:03 ` Martin K. Petersen 1 sibling, 1 reply; 82+ messages in thread From: Joe Perches @ 2019-09-12 15:34 UTC (permalink / raw) To: Bart Van Assche, Martin K. Petersen, Dan Williams Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Steve French, Vishal Verma, Mauro Carvalho Chehab, Dmitry Vyukov, Tobin C. Harding 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. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-12 15:34 ` Joe Perches @ 2019-09-12 20:01 ` Bart Van Assche 2019-09-12 20:34 ` Joe Perches 2019-09-13 12:56 ` Matthew Wilcox 0 siblings, 2 replies; 82+ messages in thread From: Bart Van Assche @ 2019-09-12 20:01 UTC (permalink / raw) To: Joe Perches, Martin K. Petersen, Dan Williams Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Steve French, Vishal Verma, Mauro Carvalho Chehab, Dmitry Vyukov, Tobin C. Harding 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 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-12 20:01 ` Bart Van Assche @ 2019-09-12 20:34 ` Joe Perches 2019-09-13 14:26 ` Rob Herring 2019-09-13 12:56 ` Matthew Wilcox 1 sibling, 1 reply; 82+ messages in thread From: Joe Perches @ 2019-09-12 20:34 UTC (permalink / raw) To: Bart Van Assche, Martin K. Petersen, Dan Williams Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Steve French, Vishal Verma, Mauro Carvalho Chehab, Dmitry Vyukov, Tobin C. Harding 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. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-12 20:34 ` Joe Perches @ 2019-09-13 14:26 ` Rob Herring 2019-09-13 18:42 ` Joe Perches 0 siblings, 1 reply; 82+ messages in thread From: Rob Herring @ 2019-09-13 14:26 UTC (permalink / raw) To: Joe Perches Cc: Dave Jiang, Bart Van Assche, ksummit, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Vishal Verma, Dmitry Vyukov, Mauro Carvalho Chehab, Steve French, Tobin C. Harding 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 _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-13 14:26 ` Rob Herring @ 2019-09-13 18:42 ` Joe Perches 2019-09-13 19:17 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 82+ messages in thread From: Joe Perches @ 2019-09-13 18:42 UTC (permalink / raw) To: Rob Herring Cc: Dave Jiang, Bart Van Assche, ksummit, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Vishal Verma, Dmitry Vyukov, Mauro Carvalho Chehab, Steve French, Tobin C. Harding 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 _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-13 18:42 ` Joe Perches @ 2019-09-13 19:17 ` Mauro Carvalho Chehab 2019-09-13 20:33 ` Joe Perches 0 siblings, 1 reply; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-13 19:17 UTC (permalink / raw) To: Joe Perches Cc: Dave Jiang, Bart Van Assche, ksummit, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Vishal Verma, Dmitry Vyukov, Steve French, Tobin C. Harding 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 _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-13 19:17 ` Mauro Carvalho Chehab @ 2019-09-13 20:33 ` Joe Perches 0 siblings, 0 replies; 82+ messages in thread From: Joe Perches @ 2019-09-13 20:33 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Dave Jiang, Bart Van Assche, ksummit, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Vishal Verma, Dmitry Vyukov, Steve French, Tobin C. Harding 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] _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-12 20:01 ` Bart Van Assche 2019-09-12 20:34 ` Joe Perches @ 2019-09-13 12:56 ` Matthew Wilcox 2019-09-13 13:54 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 82+ messages in thread From: Matthew Wilcox @ 2019-09-13 12:56 UTC (permalink / raw) To: Bart Van Assche Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Dmitry Vyukov, Vishal Verma, Mauro Carvalho Chehab, Steve French, Tobin C. Harding [-- Attachment #1.1: Type: text/plain, Size: 1305 bytes --] 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 > [-- Attachment #1.2: Type: text/html, Size: 1939 bytes --] [-- Attachment #2: Type: text/plain, Size: 186 bytes --] _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-13 12:56 ` Matthew Wilcox @ 2019-09-13 13:54 ` Mauro Carvalho Chehab 2019-09-13 14:59 ` Guenter Roeck 0 siblings, 1 reply; 82+ messages in thread From: Mauro Carvalho Chehab @ 2019-09-13 13:54 UTC (permalink / raw) To: Matthew Wilcox Cc: Dave Jiang, Bart Van Assche, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Vishal Verma, Dmitry Vyukov, Steve French, Tobin C. Harding 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 _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-13 13:54 ` Mauro Carvalho Chehab @ 2019-09-13 14:59 ` Guenter Roeck 0 siblings, 0 replies; 82+ messages in thread From: Guenter Roeck @ 2019-09-13 14:59 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Dave Jiang, Bart Van Assche, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Steve French, Vishal Verma, Dmitry Vyukov, Tobin C. Harding 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 _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-12 13:31 ` Bart Van Assche 2019-09-12 15:34 ` Joe Perches @ 2019-09-13 22:03 ` Martin K. Petersen 1 sibling, 0 replies; 82+ messages in thread From: Martin K. Petersen @ 2019-09-13 22:03 UTC (permalink / raw) To: Bart Van Assche Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Dmitry Vyukov, Vishal Verma, Mauro Carvalho Chehab, Steve French, Tobin C. Harding 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 _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles 2019-09-11 15:48 [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams ` (3 preceding siblings ...) 2019-09-11 16:40 ` [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen @ 2019-09-12 13:10 ` Bart Van Assche 4 siblings, 0 replies; 82+ messages in thread From: Bart Van Assche @ 2019-09-12 13:10 UTC (permalink / raw) To: Dan Williams, linux-kernel Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, Dmitry Vyukov, Vishal Verma, Mauro Carvalho Chehab, Steve French, Tobin C. Harding 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. _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 82+ messages in thread
end of thread, other threads:[~2019-11-08 2:42 UTC | newest] Thread overview: 82+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-11 15:48 [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams 2019-09-13 15:37 ` Mauro Carvalho Chehab 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: " Dan Williams 2019-09-16 12:35 ` Jani Nikula 2019-10-01 13:55 ` Jonathan Corbet 2019-10-01 18:17 ` Martin K. Petersen 2019-11-07 20:13 ` Jonathan Corbet 2019-11-08 2:41 ` Dan Williams 2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams 2019-09-11 17:42 ` Vishal Verma 2019-09-11 18:43 ` Dan Carpenter 2019-09-11 22:11 ` Jens Axboe 2019-09-12 7:41 ` Dan Williams [not found] ` <CANiq72k2so3ZcqA3iRziGY=Shd_B1=qGoXXROeAF7Y3+pDmqyA@mail.gmail.com> 2019-09-12 10:18 ` Joe Perches 2019-09-13 7:09 ` Jonathan Corbet 2019-09-13 11:48 ` Dan Carpenter 2019-09-13 12:18 ` Dan Williams 2019-09-13 15:00 ` Randy Dunlap 2019-09-13 15:46 ` Rob Herring 2019-09-13 16:42 ` Joe Perches 2019-09-13 19:32 ` Rob Herring 2019-09-13 17:57 ` Geert Uytterhoeven 2019-09-16 12:42 ` Jani Nikula [not found] ` <20190917161608.GA12866@ziepe.ca> 2019-09-17 21:59 ` Dan Williams 2019-09-13 21:44 ` Martin K. Petersen 2019-09-16 7:01 ` Dan Carpenter 2019-09-16 17:08 ` Martin K. Petersen 2019-09-16 17:15 ` Mark Brown 2019-09-11 20:30 ` Joe Perches 2019-09-13 16:19 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Mauro Carvalho Chehab 2019-09-13 16:19 ` Mauro Carvalho Chehab 2019-09-17 3:35 ` [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) Kees Cook 2019-09-17 13:28 ` Mauro Carvalho Chehab 2019-09-17 16:33 ` Kees Cook 2019-09-18 11:23 ` Mauro Carvalho Chehab 2019-09-18 17:39 ` Kees Cook 2019-09-18 18:35 ` Mauro Carvalho Chehab 2019-09-21 19:13 ` Jonathan Corbet 2019-09-21 19:45 ` Mauro Carvalho Chehab 2019-09-23 22:45 ` Kees Cook 2019-09-18 12:36 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Laurent Pinchart 2019-09-18 13:57 ` Mauro Carvalho Chehab 2019-09-18 17:27 ` Laurent Pinchart 2019-09-18 18:48 ` Mauro Carvalho Chehab 2019-09-19 7:08 ` Dan Carpenter 2019-09-20 5:29 ` Joe Perches 2019-09-20 14:09 ` Daniel Vetter 2019-09-19 6:56 ` Dan Carpenter 2019-09-19 7:22 ` Geert Uytterhoeven 2019-09-19 8:49 ` Jani Nikula 2019-09-19 8:58 ` Geert Uytterhoeven 2019-09-19 9:52 ` Jani Nikula 2019-09-20 14:53 ` Laurent Pinchart 2019-09-20 14:59 ` Doug Anderson 2019-09-21 8:56 ` Jani Nikula 2019-09-23 15:58 ` Doug Anderson 2019-09-23 16:04 ` Jonathan Corbet 2019-09-19 9:52 ` Mauro Carvalho Chehab 2019-09-25 17:13 ` Joe Perches 2019-09-25 18:40 ` Kees Cook 2019-09-26 15:14 ` Joe Perches 2019-09-26 15:53 ` Kees Cook 2019-09-26 16:02 ` Joe Perches 2019-09-26 16:24 ` Kees Cook 2019-09-26 10:25 ` Geert Uytterhoeven 2019-09-18 13:59 ` [Ksummit-discuss] [PATCH v2] " Mauro Carvalho Chehab [not found] ` <1e479f17-dbc8-b44d-bd1e-4229a6dbf151@collabora.com> 2019-09-18 14:11 ` Mauro Carvalho Chehab 2019-09-11 16:40 ` [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen 2019-09-12 13:31 ` Bart Van Assche 2019-09-12 15:34 ` Joe Perches 2019-09-12 20:01 ` Bart Van Assche 2019-09-12 20:34 ` Joe Perches 2019-09-13 14:26 ` Rob Herring 2019-09-13 18:42 ` Joe Perches 2019-09-13 19:17 ` Mauro Carvalho Chehab 2019-09-13 20:33 ` Joe Perches 2019-09-13 12:56 ` Matthew Wilcox 2019-09-13 13:54 ` Mauro Carvalho Chehab 2019-09-13 14:59 ` Guenter Roeck 2019-09-13 22:03 ` Martin K. Petersen 2019-09-12 13:10 ` Bart Van Assche
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).