From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 030818E2 for ; Thu, 15 Nov 2018 05:49:54 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EC1848B for ; Thu, 15 Nov 2018 05:49:52 +0000 (UTC) Date: Wed, 14 Nov 2018 21:49:22 -0800 From: Mauro Carvalho Chehab To: Dan Williams Message-ID: <20181114214922.07d31676@silica.lan> In-Reply-To: <154225760492.2499188.14152986544451112930.stgit@dwillia2-desk3.amr.corp.intel.com> References: <154225759358.2499188.15268218778137905050.stgit@dwillia2-desk3.amr.corp.intel.com> <154225760492.2499188.14152986544451112930.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ksummit-discuss@lists.linuxfoundation.org, linux-nvdimm@lists.01.org, vishal.l.verma@intel.com, linux-kernel@vger.kernel.org, Steve French , Greg Kroah-Hartman , Dmitry Vyukov , "Tobin C. Harding" Subject: Re: [Ksummit-discuss] [RFC PATCH 2/3] MAINTAINERS, Handbook: Subsystem Profile List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Em Wed, 14 Nov 2018 20:53:25 -0800 Dan Williams escreveu: > As presented at the 2018 Linux Plumbers conference [1], the Subsystem > Profile is proposed as a way to reduce friction between committers and > maintainers and perhaps encourage conversations amongst maintainers > about best practice policies. >=20 > The profile contains short answers to some of the common policy > questions a contributor might have, or that a maintainer might consider > formalizing. The current list of maintenance policies is: >=20 > Overview: General introduction to maintaining the subsystem > Core: List of source files considered core > Leaf: List of source files that consume core functionality > Patches or Pull requests: Simple statement of expected submission format > Last -rc for new feature submissions: Expected lead time for submissions > Last -rc to merge features: Deadline for merge decisions > Non-author Ack / Review Tags Required: Patch review economics > Test Suite: Pass this suite before requesting inclusion > Resubmit Cadence: When to ping the maintainer > Trusted Reviewers: Help for triaging patches There is one detail with regards to reviewing process that I'm not sure how to express. There are some subsystems with co-maintainers, in the sense that all co-maintainers are equally responsible for the subsystem. There are other cases where there are sub-maintainers. That's, for example, the model we use on media. There, we have different sub-maintainers for: - V4L2 drivers - Camera Sensors - Remote Controllers - HDMI CEC - DVB - Media Controller The usual workflow is that they work as both reviewers and committers. After they commit a certain amount of patches, they submit for me to do a final review. This way, most of media patches have at least two SOBs from non-authors. On this model, a sub-maintainer is more than a trusted reviewer. Not sure how to reflect it on this template. I'll do a better review of the profile when I'll try to write a subsystem profile for media. Regards, Mauro > Time Zone / Office Hours: When might a maintainer be available > Checkpatch / Style Cleanups: Policy on pure cleanup patches > Off-list review: Request for review gates > TODO: Potential development tasks up for grabs, or active focus areas >=20 > The goal of the Subsystem Profile is to set expectations for > contributors and interim or replacement maintainers for a subsystem. >=20 > See Documentation/maintainer/subsystem-profile.rst for more details, and > a follow-on example profile for the libnvdimm subsystem. >=20 > [1]: https://linuxplumbersconf.org/event/2/contributions/59/ >=20 > Cc: Jonathan Corbet > Cc: Thomas Gleixner > Cc: Mauro Carvalho Chehab > Cc: Steve French > Cc: Greg Kroah-Hartman > Cc: Linus Torvalds > Cc: Tobin C. Harding > Cc: Olof Johansson > Cc: Martin K. Petersen > Cc: Daniel Vetter > Cc: Joe Perches > Cc: Dmitry Vyukov > Signed-off-by: Dan Williams > --- > Documentation/maintainer/index.rst | 1=20 > Documentation/maintainer/subsystem-profile.rst | 145 ++++++++++++++++++= ++++++ > MAINTAINERS | 4 + > 3 files changed, 150 insertions(+) > create mode 100644 Documentation/maintainer/subsystem-profile.rst >=20 > diff --git a/Documentation/maintainer/index.rst b/Documentation/maintaine= r/index.rst > index 2a14916930cb..1e6b1aaa6024 100644 > --- a/Documentation/maintainer/index.rst > +++ b/Documentation/maintainer/index.rst > @@ -11,4 +11,5 @@ additions to this manual. > =20 > configure-git > pull-requests > + subsystem-profile > =20 > diff --git a/Documentation/maintainer/subsystem-profile.rst b/Documentati= on/maintainer/subsystem-profile.rst > new file mode 100644 > index 000000000000..a74b624e0972 > --- /dev/null > +++ b/Documentation/maintainer/subsystem-profile.rst > @@ -0,0 +1,145 @@ > +.. _subsystemprofile: > + > +Subsystem Profile > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +The Subsystem Profile is a collection of policy positions that a > +maintainer or maintainer team establishes for the their subsystem. While > +there is a wide range of technical nuance on maintaining disparate > +sections of the kernel, the Subsystem Profile documents a known set of > +major process policies that vary between subsystems. What follows is a > +list of policy questions a maintainer can answer and include a document > +in the kernel, or on an external website. It advertises to other > +maintainers and contributors the local policy of the subsystem. Some > +sections are optional like "Overview", "Off-list review", and "TODO". > +The others are recommended for all subsystems to address, but no section > +is mandatory. In addition there are no wrong answers, just document how > +a subsystem typically operates. Note that the profile follows the > +subsystem not the maintainer, i.e. there is no expectation that a > +maintainer of multiple subsystems deploys the same policy across those > +subsystems. > + > + > +Overview > +-------- > +In this optional section of the profile provide a free form overview of > +the subsystem written as a hand-off document. In other words write a > +note to someone that would receive the =E2=80=9Ckeys to the castle=E2=80= =9D in the event > +of extended or unexpected absence. =E2=80=9CSo, you have recently become= the > +maintainer of the XYZ subsystem, condolences, it is a thankless job, > +here is the lay of the land.=E2=80=9D Details to consider are the extend= ed > +details that are not included in MAINTAINERS, and not addressed by the > +other profile questions below. For example details like, who has access > +to the git tree, branches that are pulled into -next, relevant > +specifications, issue trackers, and sensitive code areas. If available > +the Overview should link to other subsystem documentation that may > +clarify, re-iterate, emphasize / de-emphasize portions of the global > +process documentation for contributors (CodingStyle, SubmittingPatches, > +etc...). > + > + > +Core > +---- > +A list of F: tags (as described by MAINTAINERS) listing what the > +maintainer considers to be core files. The review and lead time > +constraints for 'core' code may be stricter given the increased > +sensitivity and risk of change. > + > + > +Patches or Pull requests > +------------------------ > +Some subsystems allow contributors to send pull requests, most require > +mailed patches. State =E2=80=9CPatches only=E2=80=9D, or =E2=80=9CPull r= equests accepted=E2=80=9D. > + > + > +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. The answer may be different for > +'Core:' files, include a second entry prefixed with 'Core:' if so. > + > + > +Last -rc to merge features > +-------------------------- > +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. The answer may be different for > +'Core:' files, include a second entry prefixed with 'Core:' if so. > + > + > +Non-author Ack / Review Tags Required > +------------------------------------- > +Let contributors and other maintainers know whether they can expect to > +see the maintainer self-commit patches without 3rd-party review. Some > +subsystem developer communities are so small as to make this requirement > +impractical. Others may have been bootstrapped by a submission of > +self-reviewed code at the outset, but have since moved to a > +non-author review-required stance. This section sets expectations on the > +code-review economics in the subsystem. For example, can a contributor > +trade review of a maintainer's, or other contributor's patches in > +exchange for consideration of their own. > + > + > +Test Suite > +---------- > +Indicate the test suite all patches are expected to pass before being > +submitted for inclusion consideration. > + > + > +Resubmit Cadence > +---------------- > +Define a rate at which a contributor should wait to resubmit a patchset > +that has not yet received comments. A general guideline is to try to > +meet a deadline of 1 - 2 weeks to acknowledge starting consideration for > +a patch set. > + > + > +Trusted Reviewers > +----------------- > +While a maintainer / maintainer-team is expected to be reviewer of last > +resort the review load is less onerous when distributed amongst > +contributors and or a trusted set of individuals. This section is > +distinct from the R: tag (Designated Reviewer). Whereas R: identifies > +reviewers that should always be copied on a patch submission, the > +trusted reviewers here are individuals contributors can reach out to if > +a few 'Resubmit Cadence' intervals have gone by without maintainer > +action, or to otherwise consult for advice. > + > + > +Time Zone / Office Hours > +------------------------ > +Let contributors know the time of day when one or more maintainers are > +usually actively monitoring the mailing list. > + > + > +Checkpatch / Style Cleanups > +--------------------------- > +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 =E2=80=9CStandalone style-cleanups are welcome=E2=80= =9D, > +=E2=80=9CStyle-cleanups to existing code only welcome with other feature > +changes=E2=80=9D, or =E2=80=9CStandalone style-cleanups to existing code= are not > +welcome=E2=80=9D. > + > + > +Off-list review > +--------------- > +A maintainer may optionally require that contributors seek prior review > +of patches before initial submission for upstream. For example, > +=E2=80=9CDevelopers from organization X, please seek internal review bef= ore > +requesting upstream review=E2=80=9D. This policy identifies occasions wh= ere a > +maintainer wants to reflect some of the review load back to an > +organization. > + > + > +TODO > +---- > +In this optional section include a list of work items that might be > +suitable for onboarding a new developer to the subsystem. > diff --git a/MAINTAINERS b/MAINTAINERS > index 83b7b3943a12..bb4a83a7684d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -99,6 +99,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 the maintainer entry. This > + is either an in-tree file or a URI to a document. The > + contents of a Subsystem Profile are described in > + Documentation/maintainer/subsystem-profile.rst. > 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 >=20 > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss Cheers, Mauro From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id AE3D421190730 for ; Wed, 14 Nov 2018 21:49:53 -0800 (PST) Date: Wed, 14 Nov 2018 21:49:22 -0800 From: Mauro Carvalho Chehab Subject: Re: [Ksummit-discuss] [RFC PATCH 2/3] MAINTAINERS, Handbook: Subsystem Profile Message-ID: <20181114214922.07d31676@silica.lan> In-Reply-To: <154225760492.2499188.14152986544451112930.stgit@dwillia2-desk3.amr.corp.intel.com> References: <154225759358.2499188.15268218778137905050.stgit@dwillia2-desk3.amr.corp.intel.com> <154225760492.2499188.14152986544451112930.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: ksummit-discuss@lists.linuxfoundation.org, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org, Steve French , Greg Kroah-Hartman , Dmitry Vyukov , "Tobin C. Harding" List-ID: RW0gV2VkLCAxNCBOb3YgMjAxOCAyMDo1MzoyNSAtMDgwMApEYW4gV2lsbGlhbXMgPGRhbi5qLndp bGxpYW1zQGludGVsLmNvbT4gZXNjcmV2ZXU6Cgo+IEFzIHByZXNlbnRlZCBhdCB0aGUgMjAxOCBM aW51eCBQbHVtYmVycyBjb25mZXJlbmNlIFsxXSwgdGhlIFN1YnN5c3RlbQo+IFByb2ZpbGUgaXMg cHJvcG9zZWQgYXMgYSB3YXkgdG8gcmVkdWNlIGZyaWN0aW9uIGJldHdlZW4gY29tbWl0dGVycyBh bmQKPiBtYWludGFpbmVycyBhbmQgcGVyaGFwcyBlbmNvdXJhZ2UgY29udmVyc2F0aW9ucyBhbW9u Z3N0IG1haW50YWluZXJzCj4gYWJvdXQgYmVzdCBwcmFjdGljZSBwb2xpY2llcy4KPiAKPiBUaGUg cHJvZmlsZSBjb250YWlucyBzaG9ydCBhbnN3ZXJzIHRvIHNvbWUgb2YgdGhlIGNvbW1vbiBwb2xp Y3kKPiBxdWVzdGlvbnMgYSBjb250cmlidXRvciBtaWdodCBoYXZlLCBvciB0aGF0IGEgbWFpbnRh aW5lciBtaWdodCBjb25zaWRlcgo+IGZvcm1hbGl6aW5nLiBUaGUgY3VycmVudCBsaXN0IG9mIG1h aW50ZW5hbmNlIHBvbGljaWVzIGlzOgo+IAo+IE92ZXJ2aWV3OiBHZW5lcmFsIGludHJvZHVjdGlv biB0byBtYWludGFpbmluZyB0aGUgc3Vic3lzdGVtCj4gQ29yZTogTGlzdCBvZiBzb3VyY2UgZmls ZXMgY29uc2lkZXJlZCBjb3JlCj4gTGVhZjogTGlzdCBvZiBzb3VyY2UgZmlsZXMgdGhhdCBjb25z dW1lIGNvcmUgZnVuY3Rpb25hbGl0eQo+IFBhdGNoZXMgb3IgUHVsbCByZXF1ZXN0czogU2ltcGxl IHN0YXRlbWVudCBvZiBleHBlY3RlZCBzdWJtaXNzaW9uIGZvcm1hdAo+IExhc3QgLXJjIGZvciBu ZXcgZmVhdHVyZSBzdWJtaXNzaW9uczogRXhwZWN0ZWQgbGVhZCB0aW1lIGZvciBzdWJtaXNzaW9u cwo+IExhc3QgLXJjIHRvIG1lcmdlIGZlYXR1cmVzOiBEZWFkbGluZSBmb3IgbWVyZ2UgZGVjaXNp b25zCj4gTm9uLWF1dGhvciBBY2sgLyBSZXZpZXcgVGFncyBSZXF1aXJlZDogUGF0Y2ggcmV2aWV3 IGVjb25vbWljcwo+IFRlc3QgU3VpdGU6IFBhc3MgdGhpcyBzdWl0ZSBiZWZvcmUgcmVxdWVzdGlu ZyBpbmNsdXNpb24KPiBSZXN1Ym1pdCBDYWRlbmNlOiBXaGVuIHRvIHBpbmcgdGhlIG1haW50YWlu ZXIKCj4gVHJ1c3RlZCBSZXZpZXdlcnM6IEhlbHAgZm9yIHRyaWFnaW5nIHBhdGNoZXMKClRoZXJl IGlzIG9uZSBkZXRhaWwgd2l0aCByZWdhcmRzIHRvIHJldmlld2luZyBwcm9jZXNzIHRoYXQgSSdt IG5vdCBzdXJlCmhvdyB0byBleHByZXNzLiBUaGVyZSBhcmUgc29tZSBzdWJzeXN0ZW1zIHdpdGgg Y28tbWFpbnRhaW5lcnMsIGluIHRoZQpzZW5zZSB0aGF0IGFsbCBjby1tYWludGFpbmVycyBhcmUg ZXF1YWxseSByZXNwb25zaWJsZSBmb3IgdGhlIHN1YnN5c3RlbS4KClRoZXJlIGFyZSBvdGhlciBj YXNlcyB3aGVyZSB0aGVyZSBhcmUgc3ViLW1haW50YWluZXJzLiBUaGF0J3MsIGZvciBleGFtcGxl LAp0aGUgbW9kZWwgd2UgdXNlIG9uIG1lZGlhLiBUaGVyZSwgd2UgaGF2ZSBkaWZmZXJlbnQgc3Vi LW1haW50YWluZXJzIGZvcjoKCgktIFY0TDIgZHJpdmVycwoJLSBDYW1lcmEgU2Vuc29ycwoJLSBS ZW1vdGUgQ29udHJvbGxlcnMKCS0gSERNSSBDRUMKCS0gRFZCCgktIE1lZGlhIENvbnRyb2xsZXIK ClRoZSB1c3VhbCB3b3JrZmxvdyBpcyB0aGF0IHRoZXkgd29yayBhcyBib3RoIHJldmlld2VycyBh bmQgY29tbWl0dGVycy4KQWZ0ZXIgdGhleSBjb21taXQgYSBjZXJ0YWluIGFtb3VudCBvZiBwYXRj aGVzLCB0aGV5IHN1Ym1pdCBmb3IgbWUgdG8KZG8gYSBmaW5hbCByZXZpZXcuIFRoaXMgd2F5LCBt b3N0IG9mIG1lZGlhIHBhdGNoZXMgaGF2ZSBhdCBsZWFzdCB0d28KU09CcyBmcm9tIG5vbi1hdXRo b3JzLgoKT24gdGhpcyBtb2RlbCwgYSBzdWItbWFpbnRhaW5lciBpcyBtb3JlIHRoYW4gYSB0cnVz dGVkIHJldmlld2VyLiBOb3Qgc3VyZQpob3cgdG8gcmVmbGVjdCBpdCBvbiB0aGlzIHRlbXBsYXRl LgoKSSdsbCBkbyBhIGJldHRlciByZXZpZXcgb2YgdGhlIHByb2ZpbGUgd2hlbiBJJ2xsIHRyeSB0 byB3cml0ZSBhIHN1YnN5c3RlbQpwcm9maWxlIGZvciBtZWRpYS4KClJlZ2FyZHMsCk1hdXJvCgo+ IFRpbWUgWm9uZSAvIE9mZmljZSBIb3VyczogV2hlbiBtaWdodCBhIG1haW50YWluZXIgYmUgYXZh aWxhYmxlCj4gQ2hlY2twYXRjaCAvIFN0eWxlIENsZWFudXBzOiBQb2xpY3kgb24gcHVyZSBjbGVh bnVwIHBhdGNoZXMKPiBPZmYtbGlzdCByZXZpZXc6IFJlcXVlc3QgZm9yIHJldmlldyBnYXRlcwo+ IFRPRE86IFBvdGVudGlhbCBkZXZlbG9wbWVudCB0YXNrcyB1cCBmb3IgZ3JhYnMsIG9yIGFjdGl2 ZSBmb2N1cyBhcmVhcwo+IAo+IFRoZSBnb2FsIG9mIHRoZSBTdWJzeXN0ZW0gUHJvZmlsZSBpcyB0 byBzZXQgZXhwZWN0YXRpb25zIGZvcgo+IGNvbnRyaWJ1dG9ycyBhbmQgaW50ZXJpbSBvciByZXBs YWNlbWVudCBtYWludGFpbmVycyBmb3IgYSBzdWJzeXN0ZW0uCj4gCj4gU2VlIERvY3VtZW50YXRp b24vbWFpbnRhaW5lci9zdWJzeXN0ZW0tcHJvZmlsZS5yc3QgZm9yIG1vcmUgZGV0YWlscywgYW5k Cj4gYSBmb2xsb3ctb24gZXhhbXBsZSBwcm9maWxlIGZvciB0aGUgbGlibnZkaW1tIHN1YnN5c3Rl bS4KPiAKPiBbMV06IGh0dHBzOi8vbGludXhwbHVtYmVyc2NvbmYub3JnL2V2ZW50LzIvY29udHJp YnV0aW9ucy81OS8KPiAKPiBDYzogSm9uYXRoYW4gQ29yYmV0IDxjb3JiZXRAbHduLm5ldD4KPiBD YzogVGhvbWFzIEdsZWl4bmVyIDx0Z2x4QGxpbnV0cm9uaXguZGU+Cj4gQ2M6IE1hdXJvIENhcnZh bGhvIENoZWhhYiA8bWNoZWhhYkBrZXJuZWwub3JnPgo+IENjOiBTdGV2ZSBGcmVuY2ggPHN0ZnJl bmNoQG1pY3Jvc29mdC5jb20+Cj4gQ2M6IEdyZWcgS3JvYWgtSGFydG1hbiA8Z3JlZ2toQGxpbnV4 Zm91bmRhdGlvbi5vcmc+Cj4gQ2M6IExpbnVzIFRvcnZhbGRzIDx0b3J2YWxkc0BsaW51eC1mb3Vu ZGF0aW9uLm9yZz4KPiBDYzogVG9iaW4gQy4gSGFyZGluZyA8bWVAdG9iaW4uY2M+Cj4gQ2M6IE9s b2YgSm9oYW5zc29uIDxvbG9mQGxpeG9tLm5ldD4KPiBDYzogTWFydGluIEsuIFBldGVyc2VuIDxt YXJ0aW4ucGV0ZXJzZW5Ab3JhY2xlLmNvbT4KPiBDYzogRGFuaWVsIFZldHRlciA8ZGFuaWVsLnZl dHRlckBmZndsbC5jaD4KPiBDYzogSm9lIFBlcmNoZXMgPGpvZUBwZXJjaGVzLmNvbT4KPiBDYzog RG1pdHJ5IFZ5dWtvdiA8ZHZ5dWtvdkBnb29nbGUuY29tPgo+IFNpZ25lZC1vZmYtYnk6IERhbiBX aWxsaWFtcyA8ZGFuLmoud2lsbGlhbXNAaW50ZWwuY29tPgo+IC0tLQo+ICBEb2N1bWVudGF0aW9u L21haW50YWluZXIvaW5kZXgucnN0ICAgICAgICAgICAgIHwgICAgMSAKPiAgRG9jdW1lbnRhdGlv bi9tYWludGFpbmVyL3N1YnN5c3RlbS1wcm9maWxlLnJzdCB8ICAxNDUgKysrKysrKysrKysrKysr KysrKysrKysrCj4gIE1BSU5UQUlORVJTICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICA0ICsKPiAgMyBmaWxlcyBjaGFuZ2VkLCAxNTAgaW5zZXJ0aW9ucygrKQo+ICBjcmVh dGUgbW9kZSAxMDA2NDQgRG9jdW1lbnRhdGlvbi9tYWludGFpbmVyL3N1YnN5c3RlbS1wcm9maWxl LnJzdAo+IAo+IGRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL21haW50YWluZXIvaW5kZXgucnN0 IGIvRG9jdW1lbnRhdGlvbi9tYWludGFpbmVyL2luZGV4LnJzdAo+IGluZGV4IDJhMTQ5MTY5MzBj Yi4uMWU2YjFhYWE2MDI0IDEwMDY0NAo+IC0tLSBhL0RvY3VtZW50YXRpb24vbWFpbnRhaW5lci9p bmRleC5yc3QKPiArKysgYi9Eb2N1bWVudGF0aW9uL21haW50YWluZXIvaW5kZXgucnN0Cj4gQEAg LTExLDQgKzExLDUgQEAgYWRkaXRpb25zIHRvIHRoaXMgbWFudWFsLgo+ICAKPiAgICAgY29uZmln dXJlLWdpdAo+ICAgICBwdWxsLXJlcXVlc3RzCj4gKyAgIHN1YnN5c3RlbS1wcm9maWxlCj4gIAo+ IGRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL21haW50YWluZXIvc3Vic3lzdGVtLXByb2ZpbGUu cnN0IGIvRG9jdW1lbnRhdGlvbi9tYWludGFpbmVyL3N1YnN5c3RlbS1wcm9maWxlLnJzdAo+IG5l dyBmaWxlIG1vZGUgMTAwNjQ0Cj4gaW5kZXggMDAwMDAwMDAwMDAwLi5hNzRiNjI0ZTA5NzIKPiAt LS0gL2Rldi9udWxsCj4gKysrIGIvRG9jdW1lbnRhdGlvbi9tYWludGFpbmVyL3N1YnN5c3RlbS1w cm9maWxlLnJzdAo+IEBAIC0wLDAgKzEsMTQ1IEBACj4gKy4uIF9zdWJzeXN0ZW1wcm9maWxlOgo+ ICsKPiArU3Vic3lzdGVtIFByb2ZpbGUKPiArPT09PT09PT09PT09PT09PT0KPiArCj4gK1RoZSBT dWJzeXN0ZW0gUHJvZmlsZSBpcyBhIGNvbGxlY3Rpb24gb2YgcG9saWN5IHBvc2l0aW9ucyB0aGF0 IGEKPiArbWFpbnRhaW5lciBvciBtYWludGFpbmVyIHRlYW0gZXN0YWJsaXNoZXMgZm9yIHRoZSB0 aGVpciBzdWJzeXN0ZW0uIFdoaWxlCj4gK3RoZXJlIGlzIGEgd2lkZSByYW5nZSBvZiB0ZWNobmlj YWwgbnVhbmNlIG9uIG1haW50YWluaW5nIGRpc3BhcmF0ZQo+ICtzZWN0aW9ucyBvZiB0aGUga2Vy bmVsLCB0aGUgU3Vic3lzdGVtIFByb2ZpbGUgZG9jdW1lbnRzIGEga25vd24gc2V0IG9mCj4gK21h am9yIHByb2Nlc3MgcG9saWNpZXMgdGhhdCB2YXJ5IGJldHdlZW4gc3Vic3lzdGVtcy4gIFdoYXQg Zm9sbG93cyBpcyBhCj4gK2xpc3Qgb2YgcG9saWN5IHF1ZXN0aW9ucyBhIG1haW50YWluZXIgY2Fu IGFuc3dlciBhbmQgaW5jbHVkZSBhIGRvY3VtZW50Cj4gK2luIHRoZSBrZXJuZWwsIG9yIG9uIGFu IGV4dGVybmFsIHdlYnNpdGUuIEl0IGFkdmVydGlzZXMgdG8gb3RoZXIKPiArbWFpbnRhaW5lcnMg YW5kIGNvbnRyaWJ1dG9ycyB0aGUgbG9jYWwgcG9saWN5IG9mIHRoZSBzdWJzeXN0ZW0uIFNvbWUK PiArc2VjdGlvbnMgYXJlIG9wdGlvbmFsIGxpa2UgIk92ZXJ2aWV3IiwgIk9mZi1saXN0IHJldmll dyIsIGFuZCAiVE9ETyIuCj4gK1RoZSBvdGhlcnMgYXJlIHJlY29tbWVuZGVkIGZvciBhbGwgc3Vi c3lzdGVtcyB0byBhZGRyZXNzLCBidXQgbm8gc2VjdGlvbgo+ICtpcyBtYW5kYXRvcnkuIEluIGFk ZGl0aW9uIHRoZXJlIGFyZSBubyB3cm9uZyBhbnN3ZXJzLCBqdXN0IGRvY3VtZW50IGhvdwo+ICth IHN1YnN5c3RlbSB0eXBpY2FsbHkgb3BlcmF0ZXMuIE5vdGUgdGhhdCB0aGUgcHJvZmlsZSBmb2xs b3dzIHRoZQo+ICtzdWJzeXN0ZW0gbm90IHRoZSBtYWludGFpbmVyLCBpLmUuIHRoZXJlIGlzIG5v IGV4cGVjdGF0aW9uIHRoYXQgYQo+ICttYWludGFpbmVyIG9mIG11bHRpcGxlIHN1YnN5c3RlbXMg ZGVwbG95cyB0aGUgc2FtZSBwb2xpY3kgYWNyb3NzIHRob3NlCj4gK3N1YnN5c3RlbXMuCj4gKwo+ ICsKPiArT3ZlcnZpZXcKPiArLS0tLS0tLS0KPiArSW4gdGhpcyBvcHRpb25hbCBzZWN0aW9uIG9m IHRoZSBwcm9maWxlIHByb3ZpZGUgYSBmcmVlIGZvcm0gb3ZlcnZpZXcgb2YKPiArdGhlIHN1YnN5 c3RlbSB3cml0dGVuIGFzIGEgaGFuZC1vZmYgZG9jdW1lbnQuIEluIG90aGVyIHdvcmRzIHdyaXRl IGEKPiArbm90ZSB0byBzb21lb25lIHRoYXQgd291bGQgcmVjZWl2ZSB0aGUg4oCca2V5cyB0byB0 aGUgY2FzdGxl4oCdIGluIHRoZSBldmVudAo+ICtvZiBleHRlbmRlZCBvciB1bmV4cGVjdGVkIGFi c2VuY2UuIOKAnFNvLCB5b3UgaGF2ZSByZWNlbnRseSBiZWNvbWUgdGhlCj4gK21haW50YWluZXIg b2YgdGhlIFhZWiBzdWJzeXN0ZW0sIGNvbmRvbGVuY2VzLCBpdCBpcyBhIHRoYW5rbGVzcyBqb2Is Cj4gK2hlcmUgaXMgdGhlIGxheSBvZiB0aGUgbGFuZC7igJ0gRGV0YWlscyB0byBjb25zaWRlciBh cmUgdGhlIGV4dGVuZGVkCj4gK2RldGFpbHMgdGhhdCBhcmUgbm90IGluY2x1ZGVkIGluIE1BSU5U QUlORVJTLCBhbmQgbm90IGFkZHJlc3NlZCBieSB0aGUKPiArb3RoZXIgcHJvZmlsZSBxdWVzdGlv bnMgYmVsb3cuIEZvciBleGFtcGxlIGRldGFpbHMgbGlrZSwgd2hvIGhhcyBhY2Nlc3MKPiArdG8g dGhlIGdpdCB0cmVlLCBicmFuY2hlcyB0aGF0IGFyZSBwdWxsZWQgaW50byAtbmV4dCwgcmVsZXZh bnQKPiArc3BlY2lmaWNhdGlvbnMsIGlzc3VlIHRyYWNrZXJzLCBhbmQgc2Vuc2l0aXZlIGNvZGUg YXJlYXMuIElmIGF2YWlsYWJsZQo+ICt0aGUgT3ZlcnZpZXcgc2hvdWxkIGxpbmsgdG8gb3RoZXIg c3Vic3lzdGVtIGRvY3VtZW50YXRpb24gdGhhdCBtYXkKPiArY2xhcmlmeSwgcmUtaXRlcmF0ZSwg ZW1waGFzaXplIC8gZGUtZW1waGFzaXplIHBvcnRpb25zIG9mIHRoZSBnbG9iYWwKPiArcHJvY2Vz cyBkb2N1bWVudGF0aW9uIGZvciBjb250cmlidXRvcnMgKENvZGluZ1N0eWxlLCBTdWJtaXR0aW5n UGF0Y2hlcywKPiArZXRjLi4uKS4KPiArCj4gKwo+ICtDb3JlCj4gKy0tLS0KPiArQSBsaXN0IG9m IEY6IHRhZ3MgKGFzIGRlc2NyaWJlZCBieSBNQUlOVEFJTkVSUykgbGlzdGluZyB3aGF0IHRoZQo+ ICttYWludGFpbmVyIGNvbnNpZGVycyB0byBiZSBjb3JlIGZpbGVzLiBUaGUgcmV2aWV3IGFuZCBs ZWFkIHRpbWUKPiArY29uc3RyYWludHMgZm9yICdjb3JlJyBjb2RlIG1heSBiZSBzdHJpY3RlciBn aXZlbiB0aGUgaW5jcmVhc2VkCj4gK3NlbnNpdGl2aXR5IGFuZCByaXNrIG9mIGNoYW5nZS4KPiAr Cj4gKwo+ICtQYXRjaGVzIG9yIFB1bGwgcmVxdWVzdHMKPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCj4gK1NvbWUgc3Vic3lzdGVtcyBhbGxvdyBjb250cmlidXRvcnMgdG8gc2VuZCBwdWxsIHJl cXVlc3RzLCBtb3N0IHJlcXVpcmUKPiArbWFpbGVkIHBhdGNoZXMuIFN0YXRlIOKAnFBhdGNoZXMg b25seeKAnSwgb3Ig4oCcUHVsbCByZXF1ZXN0cyBhY2NlcHRlZOKAnS4KPiArCj4gKwo+ICtMYXN0 IC1yYyBmb3IgbmV3IGZlYXR1cmUgc3VibWlzc2lvbnMKPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCj4gK05ldyBmZWF0dXJlIHN1Ym1pc3Npb25zIHRhcmdldGluZyB0aGUg bmV4dCBtZXJnZSB3aW5kb3cgc2hvdWxkIGhhdmUKPiArdGhlaXIgZmlyc3QgcG9zdGluZyBmb3Ig Y29uc2lkZXJhdGlvbiBiZWZvcmUgdGhpcyBwb2ludC4gUGF0Y2hlcyB0aGF0Cj4gK2FyZSBzdWJt aXR0ZWQgYWZ0ZXIgdGhpcyBwb2ludCBzaG91bGQgYmUgY2xlYXIgdGhhdCB0aGV5IGFyZSB0YXJn ZXRpbmcKPiArdGhlIE5FWFQrMSBtZXJnZSB3aW5kb3csIG9yIHNob3VsZCBjb21lIHdpdGggc3Vm ZmljaWVudCBqdXN0aWZpY2F0aW9uCj4gK3doeSB0aGV5IHNob3VsZCBiZSBjb25zaWRlcmVkIG9u IGFuIGV4cGVkaXRlZCBzY2hlZHVsZS4gQSBnZW5lcmFsCj4gK2d1aWRlbGluZSBpcyB0byBzZXQg ZXhwZWN0YXRpb24gd2l0aCBjb250cmlidXRvcnMgdGhhdCBuZXcgZmVhdHVyZQo+ICtzdWJtaXNz aW9ucyBzaG91bGQgYXBwZWFyIGJlZm9yZSAtcmM1LiBUaGUgYW5zd2VyIG1heSBiZSBkaWZmZXJl bnQgZm9yCj4gKydDb3JlOicgZmlsZXMsIGluY2x1ZGUgYSBzZWNvbmQgZW50cnkgcHJlZml4ZWQg d2l0aCAnQ29yZTonIGlmIHNvLgo+ICsKPiArCj4gK0xhc3QgLXJjIHRvIG1lcmdlIGZlYXR1cmVz Cj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gK0luZGljYXRlIHRvIGNvbnRyaWJ1dG9y cyB0aGUgcG9pbnQgYXQgd2hpY2ggYW4gYXMgeWV0IHVuLWFwcGxpZWQgcGF0Y2gKPiArc2V0IHdp bGwgbmVlZCB0byB3YWl0IGZvciB0aGUgTkVYVCsxIG1lcmdlIHdpbmRvdy4gT2YgY291cnNlIHRo ZXJlIGlzIG5vCj4gK29ibGlnYXRpb24gdG8gZXZlciBleGNlcHQgYW55IGdpdmVuIHBhdGNoc2V0 LCBidXQgaWYgdGhlIHJldmlldyBoYXMgbm90Cj4gK2NvbmNsdWRlZCBieSB0aGlzIHBvaW50IHRo ZSBleHBlY3RhdGlvbiB0aGUgY29udHJpYnV0b3Igc2hvdWxkIHdhaXQgYW5kCj4gK3Jlc3VibWl0 IGZvciB0aGUgZm9sbG93aW5nIG1lcmdlIHdpbmRvdy4gVGhlIGFuc3dlciBtYXkgYmUgZGlmZmVy ZW50IGZvcgo+ICsnQ29yZTonIGZpbGVzLCBpbmNsdWRlIGEgc2Vjb25kIGVudHJ5IHByZWZpeGVk IHdpdGggJ0NvcmU6JyBpZiBzby4KPiArCj4gKwo+ICtOb24tYXV0aG9yIEFjayAvIFJldmlldyBU YWdzIFJlcXVpcmVkCj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAr TGV0IGNvbnRyaWJ1dG9ycyBhbmQgb3RoZXIgbWFpbnRhaW5lcnMga25vdyB3aGV0aGVyIHRoZXkg Y2FuIGV4cGVjdCB0bwo+ICtzZWUgdGhlIG1haW50YWluZXIgc2VsZi1jb21taXQgcGF0Y2hlcyB3 aXRob3V0IDNyZC1wYXJ0eSByZXZpZXcuIFNvbWUKPiArc3Vic3lzdGVtIGRldmVsb3BlciBjb21t dW5pdGllcyBhcmUgc28gc21hbGwgYXMgdG8gbWFrZSB0aGlzIHJlcXVpcmVtZW50Cj4gK2ltcHJh Y3RpY2FsLiBPdGhlcnMgbWF5IGhhdmUgYmVlbiBib290c3RyYXBwZWQgYnkgYSBzdWJtaXNzaW9u IG9mCj4gK3NlbGYtcmV2aWV3ZWQgY29kZSBhdCB0aGUgb3V0c2V0LCBidXQgaGF2ZSBzaW5jZSBt b3ZlZCB0byBhCj4gK25vbi1hdXRob3IgcmV2aWV3LXJlcXVpcmVkIHN0YW5jZS4gVGhpcyBzZWN0 aW9uIHNldHMgZXhwZWN0YXRpb25zIG9uIHRoZQo+ICtjb2RlLXJldmlldyBlY29ub21pY3MgaW4g dGhlIHN1YnN5c3RlbS4gRm9yIGV4YW1wbGUsIGNhbiBhIGNvbnRyaWJ1dG9yCj4gK3RyYWRlIHJl dmlldyBvZiBhIG1haW50YWluZXIncywgb3Igb3RoZXIgY29udHJpYnV0b3IncyBwYXRjaGVzIGlu Cj4gK2V4Y2hhbmdlIGZvciBjb25zaWRlcmF0aW9uIG9mIHRoZWlyIG93bi4KPiArCj4gKwo+ICtU ZXN0IFN1aXRlCj4gKy0tLS0tLS0tLS0KPiArSW5kaWNhdGUgdGhlIHRlc3Qgc3VpdGUgYWxsIHBh dGNoZXMgYXJlIGV4cGVjdGVkIHRvIHBhc3MgYmVmb3JlIGJlaW5nCj4gK3N1Ym1pdHRlZCBmb3Ig aW5jbHVzaW9uIGNvbnNpZGVyYXRpb24uCj4gKwo+ICsKPiArUmVzdWJtaXQgQ2FkZW5jZQo+ICst LS0tLS0tLS0tLS0tLS0tCj4gK0RlZmluZSBhIHJhdGUgYXQgd2hpY2ggYSBjb250cmlidXRvciBz aG91bGQgd2FpdCB0byByZXN1Ym1pdCBhIHBhdGNoc2V0Cj4gK3RoYXQgaGFzIG5vdCB5ZXQgcmVj ZWl2ZWQgY29tbWVudHMuIEEgZ2VuZXJhbCBndWlkZWxpbmUgaXMgdG8gdHJ5IHRvCj4gK21lZXQg YSBkZWFkbGluZSBvZiAxIC0gMiB3ZWVrcyB0byBhY2tub3dsZWRnZSBzdGFydGluZyBjb25zaWRl cmF0aW9uIGZvcgo+ICthIHBhdGNoIHNldC4KPiArCj4gKwo+ICtUcnVzdGVkIFJldmlld2Vycwo+ ICstLS0tLS0tLS0tLS0tLS0tLQo+ICtXaGlsZSBhIG1haW50YWluZXIgLyBtYWludGFpbmVyLXRl YW0gaXMgZXhwZWN0ZWQgdG8gYmUgcmV2aWV3ZXIgb2YgbGFzdAo+ICtyZXNvcnQgdGhlIHJldmll dyBsb2FkIGlzIGxlc3Mgb25lcm91cyB3aGVuIGRpc3RyaWJ1dGVkIGFtb25nc3QKPiArY29udHJp YnV0b3JzIGFuZCBvciBhIHRydXN0ZWQgc2V0IG9mIGluZGl2aWR1YWxzLiAgVGhpcyBzZWN0aW9u IGlzCj4gK2Rpc3RpbmN0IGZyb20gdGhlIFI6IHRhZyAoRGVzaWduYXRlZCBSZXZpZXdlcikuIFdo ZXJlYXMgUjogaWRlbnRpZmllcwo+ICtyZXZpZXdlcnMgdGhhdCBzaG91bGQgYWx3YXlzIGJlIGNv cGllZCBvbiBhIHBhdGNoIHN1Ym1pc3Npb24sIHRoZQo+ICt0cnVzdGVkIHJldmlld2VycyBoZXJl IGFyZSBpbmRpdmlkdWFscyBjb250cmlidXRvcnMgY2FuIHJlYWNoIG91dCB0byBpZgo+ICthIGZl dyAnUmVzdWJtaXQgQ2FkZW5jZScgaW50ZXJ2YWxzIGhhdmUgZ29uZSBieSB3aXRob3V0IG1haW50 YWluZXIKPiArYWN0aW9uLCBvciB0byBvdGhlcndpc2UgY29uc3VsdCBmb3IgYWR2aWNlLgo+ICsK PiArCj4gK1RpbWUgWm9uZSAvIE9mZmljZSBIb3Vycwo+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KPiArTGV0IGNvbnRyaWJ1dG9ycyBrbm93IHRoZSB0aW1lIG9mIGRheSB3aGVuIG9uZSBvciBt b3JlIG1haW50YWluZXJzIGFyZQo+ICt1c3VhbGx5IGFjdGl2ZWx5IG1vbml0b3JpbmcgdGhlIG1h aWxpbmcgbGlzdC4KPiArCj4gKwo+ICtDaGVja3BhdGNoIC8gU3R5bGUgQ2xlYW51cHMKPiArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gK0ZvciBzdWJzeXN0ZW1zIHdpdGggbG9uZyBzdGFu ZGluZyBjb2RlIGJhc2VzIGl0IGlzIHJlYXNvbmFibGUgdG8gZGVjbGluZQo+ICt0byBhY2NlcHQg cHVyZSBjb2Rpbmctc3R5bGUgZml4dXAgcGF0Y2hlcy4gVGhpcyBpcyB3aGVyZSB5b3UgY2FuIGxl dAo+ICtjb250cmlidXRvcnMga25vdyDigJxTdGFuZGFsb25lIHN0eWxlLWNsZWFudXBzIGFyZSB3 ZWxjb21l4oCdLAo+ICvigJxTdHlsZS1jbGVhbnVwcyB0byBleGlzdGluZyBjb2RlIG9ubHkgd2Vs Y29tZSB3aXRoIG90aGVyIGZlYXR1cmUKPiArY2hhbmdlc+KAnSwgb3Ig4oCcU3RhbmRhbG9uZSBz dHlsZS1jbGVhbnVwcyB0byBleGlzdGluZyBjb2RlIGFyZSBub3QKPiArd2VsY29tZeKAnS4KPiAr Cj4gKwo+ICtPZmYtbGlzdCByZXZpZXcKPiArLS0tLS0tLS0tLS0tLS0tCj4gK0EgbWFpbnRhaW5l ciBtYXkgb3B0aW9uYWxseSByZXF1aXJlIHRoYXQgY29udHJpYnV0b3JzIHNlZWsgcHJpb3IgcmV2 aWV3Cj4gK29mIHBhdGNoZXMgYmVmb3JlIGluaXRpYWwgc3VibWlzc2lvbiBmb3IgdXBzdHJlYW0u IEZvciBleGFtcGxlLAo+ICvigJxEZXZlbG9wZXJzIGZyb20gb3JnYW5pemF0aW9uIFgsIHBsZWFz ZSBzZWVrIGludGVybmFsIHJldmlldyBiZWZvcmUKPiArcmVxdWVzdGluZyB1cHN0cmVhbSByZXZp ZXfigJ0uIFRoaXMgcG9saWN5IGlkZW50aWZpZXMgb2NjYXNpb25zIHdoZXJlIGEKPiArbWFpbnRh aW5lciB3YW50cyB0byByZWZsZWN0IHNvbWUgb2YgdGhlIHJldmlldyBsb2FkIGJhY2sgdG8gYW4K PiArb3JnYW5pemF0aW9uLgo+ICsKPiArCj4gK1RPRE8KPiArLS0tLQo+ICtJbiB0aGlzIG9wdGlv bmFsIHNlY3Rpb24gaW5jbHVkZSBhIGxpc3Qgb2Ygd29yayBpdGVtcyB0aGF0IG1pZ2h0IGJlCj4g K3N1aXRhYmxlIGZvciBvbmJvYXJkaW5nIGEgbmV3IGRldmVsb3BlciB0byB0aGUgc3Vic3lzdGVt Lgo+IGRpZmYgLS1naXQgYS9NQUlOVEFJTkVSUyBiL01BSU5UQUlORVJTCj4gaW5kZXggODNiN2Iz OTQzYTEyLi5iYjRhODNhNzY4NGQgMTAwNjQ0Cj4gLS0tIGEvTUFJTlRBSU5FUlMKPiArKysgYi9N QUlOVEFJTkVSUwo+IEBAIC05OSw2ICs5OSwxMCBAQCBEZXNjcmlwdGlvbnMgb2Ygc2VjdGlvbiBl bnRyaWVzOgo+ICAJICAgT2Jzb2xldGU6CU9sZCBjb2RlLiBTb21ldGhpbmcgdGFnZ2VkIG9ic29s ZXRlIGdlbmVyYWxseSBtZWFucwo+ICAJCQlpdCBoYXMgYmVlbiByZXBsYWNlZCBieSBhIGJldHRl ciBzeXN0ZW0gYW5kIHlvdQo+ICAJCQlzaG91bGQgYmUgdXNpbmcgdGhhdC4KPiArCVA6IFN1YnN5 c3RlbSBQcm9maWxlIGRvY3VtZW50IGZvciB0aGUgbWFpbnRhaW5lciBlbnRyeS4gIFRoaXMKPiAr CSAgIGlzIGVpdGhlciBhbiBpbi10cmVlIGZpbGUgb3IgYSBVUkkgdG8gYSBkb2N1bWVudC4gIFRo ZQo+ICsJICAgY29udGVudHMgb2YgYSBTdWJzeXN0ZW0gUHJvZmlsZSBhcmUgZGVzY3JpYmVkIGlu Cj4gKwkgICBEb2N1bWVudGF0aW9uL21haW50YWluZXIvc3Vic3lzdGVtLXByb2ZpbGUucnN0Lgo+ ICAJRjogRmlsZXMgYW5kIGRpcmVjdG9yaWVzIHdpdGggd2lsZGNhcmQgcGF0dGVybnMuCj4gIAkg ICBBIHRyYWlsaW5nIHNsYXNoIGluY2x1ZGVzIGFsbCBmaWxlcyBhbmQgc3ViZGlyZWN0b3J5IGZp bGVzLgo+ICAJICAgRjoJZHJpdmVycy9uZXQvCWFsbCBmaWxlcyBpbiBhbmQgYmVsb3cgZHJpdmVy cy9uZXQKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+IEtzdW1taXQtZGlzY3VzcyBtYWlsaW5nIGxpc3QKPiBLc3VtbWl0LWRpc2N1c3NAbGlzdHMu bGludXhmb3VuZGF0aW9uLm9yZwo+IGh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9uLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2tzdW1taXQtZGlzY3VzcwoKCgoKQ2hlZXJzLApNYXVybwpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eC1udmRpbW0gbWFp bGluZyBsaXN0CkxpbnV4LW52ZGltbUBsaXN0cy4wMS5vcmcKaHR0cHM6Ly9saXN0cy4wMS5vcmcv bWFpbG1hbi9saXN0aW5mby9saW51eC1udmRpbW0K From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B98C2C43441 for ; Thu, 15 Nov 2018 05:49:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 68E5D2087A for ; Thu, 15 Nov 2018 05:49:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="QxeuA7PG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68E5D2087A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728536AbeKOP4R (ORCPT ); Thu, 15 Nov 2018 10:56:17 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:34806 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726689AbeKOP4R (ORCPT ); Thu, 15 Nov 2018 10:56:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uIj9L7Z9PP7yDreP7uGF00aHo15PGs45oEWG9RRcus0=; b=QxeuA7PG8foUv65UYR8jrBjhe LivM03irRF13ClnST8XlDTi8WAckndUGWU9Py/SzINKBQXjdDSEY++R0XI+v6ZNK9db4se5/IWe4L nQQvozEbON+X/sBE8+UmXv5JzijSFiNkBJUlvsxoRJuiB8rrosIN0i4Ub6hijKUhVFNGyGGQKI1ci Z0XDn06SyVRhwCX175yKzAdlo5SI/4J6F6/DJGbW2RrugaoVCgEnNu3oodzX1cQcp1YJrON++li1i fi04+78KcZKD0fSrN1UqCnfO/lJuPkFacOa9FtraQbxGr0YnBACX8JoZEXf9ipDjMSqkaaHZEnw4w z0LofBbjw==; Received: from 189.27.28.95.dynamic.adsl.gvt.net.br ([189.27.28.95] helo=silica.lan) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1gNAXH-0003so-5J; Thu, 15 Nov 2018 05:49:52 +0000 Date: Wed, 14 Nov 2018 21:49:22 -0800 From: Mauro Carvalho Chehab To: Dan Williams Cc: linux-kernel@vger.kernel.org, vishal.l.verma@intel.com, ksummit-discuss@lists.linuxfoundation.org, Greg Kroah-Hartman , linux-nvdimm@lists.01.org, Dmitry Vyukov , Steve French , "Tobin C. Harding" Subject: Re: [Ksummit-discuss] [RFC PATCH 2/3] MAINTAINERS, Handbook: Subsystem Profile Message-ID: <20181114214922.07d31676@silica.lan> In-Reply-To: <154225760492.2499188.14152986544451112930.stgit@dwillia2-desk3.amr.corp.intel.com> References: <154225759358.2499188.15268218778137905050.stgit@dwillia2-desk3.amr.corp.intel.com> <154225760492.2499188.14152986544451112930.stgit@dwillia2-desk3.amr.corp.intel.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Wed, 14 Nov 2018 20:53:25 -0800 Dan Williams escreveu: > As presented at the 2018 Linux Plumbers conference [1], the Subsystem > Profile is proposed as a way to reduce friction between committers and > maintainers and perhaps encourage conversations amongst maintainers > about best practice policies. >=20 > The profile contains short answers to some of the common policy > questions a contributor might have, or that a maintainer might consider > formalizing. The current list of maintenance policies is: >=20 > Overview: General introduction to maintaining the subsystem > Core: List of source files considered core > Leaf: List of source files that consume core functionality > Patches or Pull requests: Simple statement of expected submission format > Last -rc for new feature submissions: Expected lead time for submissions > Last -rc to merge features: Deadline for merge decisions > Non-author Ack / Review Tags Required: Patch review economics > Test Suite: Pass this suite before requesting inclusion > Resubmit Cadence: When to ping the maintainer > Trusted Reviewers: Help for triaging patches There is one detail with regards to reviewing process that I'm not sure how to express. There are some subsystems with co-maintainers, in the sense that all co-maintainers are equally responsible for the subsystem. There are other cases where there are sub-maintainers. That's, for example, the model we use on media. There, we have different sub-maintainers for: - V4L2 drivers - Camera Sensors - Remote Controllers - HDMI CEC - DVB - Media Controller The usual workflow is that they work as both reviewers and committers. After they commit a certain amount of patches, they submit for me to do a final review. This way, most of media patches have at least two SOBs from non-authors. On this model, a sub-maintainer is more than a trusted reviewer. Not sure how to reflect it on this template. I'll do a better review of the profile when I'll try to write a subsystem profile for media. Regards, Mauro > Time Zone / Office Hours: When might a maintainer be available > Checkpatch / Style Cleanups: Policy on pure cleanup patches > Off-list review: Request for review gates > TODO: Potential development tasks up for grabs, or active focus areas >=20 > The goal of the Subsystem Profile is to set expectations for > contributors and interim or replacement maintainers for a subsystem. >=20 > See Documentation/maintainer/subsystem-profile.rst for more details, and > a follow-on example profile for the libnvdimm subsystem. >=20 > [1]: https://linuxplumbersconf.org/event/2/contributions/59/ >=20 > Cc: Jonathan Corbet > Cc: Thomas Gleixner > Cc: Mauro Carvalho Chehab > Cc: Steve French > Cc: Greg Kroah-Hartman > Cc: Linus Torvalds > Cc: Tobin C. Harding > Cc: Olof Johansson > Cc: Martin K. Petersen > Cc: Daniel Vetter > Cc: Joe Perches > Cc: Dmitry Vyukov > Signed-off-by: Dan Williams > --- > Documentation/maintainer/index.rst | 1=20 > Documentation/maintainer/subsystem-profile.rst | 145 ++++++++++++++++++= ++++++ > MAINTAINERS | 4 + > 3 files changed, 150 insertions(+) > create mode 100644 Documentation/maintainer/subsystem-profile.rst >=20 > diff --git a/Documentation/maintainer/index.rst b/Documentation/maintaine= r/index.rst > index 2a14916930cb..1e6b1aaa6024 100644 > --- a/Documentation/maintainer/index.rst > +++ b/Documentation/maintainer/index.rst > @@ -11,4 +11,5 @@ additions to this manual. > =20 > configure-git > pull-requests > + subsystem-profile > =20 > diff --git a/Documentation/maintainer/subsystem-profile.rst b/Documentati= on/maintainer/subsystem-profile.rst > new file mode 100644 > index 000000000000..a74b624e0972 > --- /dev/null > +++ b/Documentation/maintainer/subsystem-profile.rst > @@ -0,0 +1,145 @@ > +.. _subsystemprofile: > + > +Subsystem Profile > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +The Subsystem Profile is a collection of policy positions that a > +maintainer or maintainer team establishes for the their subsystem. While > +there is a wide range of technical nuance on maintaining disparate > +sections of the kernel, the Subsystem Profile documents a known set of > +major process policies that vary between subsystems. What follows is a > +list of policy questions a maintainer can answer and include a document > +in the kernel, or on an external website. It advertises to other > +maintainers and contributors the local policy of the subsystem. Some > +sections are optional like "Overview", "Off-list review", and "TODO". > +The others are recommended for all subsystems to address, but no section > +is mandatory. In addition there are no wrong answers, just document how > +a subsystem typically operates. Note that the profile follows the > +subsystem not the maintainer, i.e. there is no expectation that a > +maintainer of multiple subsystems deploys the same policy across those > +subsystems. > + > + > +Overview > +-------- > +In this optional section of the profile provide a free form overview of > +the subsystem written as a hand-off document. In other words write a > +note to someone that would receive the =E2=80=9Ckeys to the castle=E2=80= =9D in the event > +of extended or unexpected absence. =E2=80=9CSo, you have recently become= the > +maintainer of the XYZ subsystem, condolences, it is a thankless job, > +here is the lay of the land.=E2=80=9D Details to consider are the extend= ed > +details that are not included in MAINTAINERS, and not addressed by the > +other profile questions below. For example details like, who has access > +to the git tree, branches that are pulled into -next, relevant > +specifications, issue trackers, and sensitive code areas. If available > +the Overview should link to other subsystem documentation that may > +clarify, re-iterate, emphasize / de-emphasize portions of the global > +process documentation for contributors (CodingStyle, SubmittingPatches, > +etc...). > + > + > +Core > +---- > +A list of F: tags (as described by MAINTAINERS) listing what the > +maintainer considers to be core files. The review and lead time > +constraints for 'core' code may be stricter given the increased > +sensitivity and risk of change. > + > + > +Patches or Pull requests > +------------------------ > +Some subsystems allow contributors to send pull requests, most require > +mailed patches. State =E2=80=9CPatches only=E2=80=9D, or =E2=80=9CPull r= equests accepted=E2=80=9D. > + > + > +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. The answer may be different for > +'Core:' files, include a second entry prefixed with 'Core:' if so. > + > + > +Last -rc to merge features > +-------------------------- > +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. The answer may be different for > +'Core:' files, include a second entry prefixed with 'Core:' if so. > + > + > +Non-author Ack / Review Tags Required > +------------------------------------- > +Let contributors and other maintainers know whether they can expect to > +see the maintainer self-commit patches without 3rd-party review. Some > +subsystem developer communities are so small as to make this requirement > +impractical. Others may have been bootstrapped by a submission of > +self-reviewed code at the outset, but have since moved to a > +non-author review-required stance. This section sets expectations on the > +code-review economics in the subsystem. For example, can a contributor > +trade review of a maintainer's, or other contributor's patches in > +exchange for consideration of their own. > + > + > +Test Suite > +---------- > +Indicate the test suite all patches are expected to pass before being > +submitted for inclusion consideration. > + > + > +Resubmit Cadence > +---------------- > +Define a rate at which a contributor should wait to resubmit a patchset > +that has not yet received comments. A general guideline is to try to > +meet a deadline of 1 - 2 weeks to acknowledge starting consideration for > +a patch set. > + > + > +Trusted Reviewers > +----------------- > +While a maintainer / maintainer-team is expected to be reviewer of last > +resort the review load is less onerous when distributed amongst > +contributors and or a trusted set of individuals. This section is > +distinct from the R: tag (Designated Reviewer). Whereas R: identifies > +reviewers that should always be copied on a patch submission, the > +trusted reviewers here are individuals contributors can reach out to if > +a few 'Resubmit Cadence' intervals have gone by without maintainer > +action, or to otherwise consult for advice. > + > + > +Time Zone / Office Hours > +------------------------ > +Let contributors know the time of day when one or more maintainers are > +usually actively monitoring the mailing list. > + > + > +Checkpatch / Style Cleanups > +--------------------------- > +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 =E2=80=9CStandalone style-cleanups are welcome=E2=80= =9D, > +=E2=80=9CStyle-cleanups to existing code only welcome with other feature > +changes=E2=80=9D, or =E2=80=9CStandalone style-cleanups to existing code= are not > +welcome=E2=80=9D. > + > + > +Off-list review > +--------------- > +A maintainer may optionally require that contributors seek prior review > +of patches before initial submission for upstream. For example, > +=E2=80=9CDevelopers from organization X, please seek internal review bef= ore > +requesting upstream review=E2=80=9D. This policy identifies occasions wh= ere a > +maintainer wants to reflect some of the review load back to an > +organization. > + > + > +TODO > +---- > +In this optional section include a list of work items that might be > +suitable for onboarding a new developer to the subsystem. > diff --git a/MAINTAINERS b/MAINTAINERS > index 83b7b3943a12..bb4a83a7684d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -99,6 +99,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 the maintainer entry. This > + is either an in-tree file or a URI to a document. The > + contents of a Subsystem Profile are described in > + Documentation/maintainer/subsystem-profile.rst. > 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 >=20 > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss Cheers, Mauro