From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82000 invoked by alias); 4 Oct 2017 13:47:44 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 81958 invoked by uid 89); 4 Oct 2017 13:47:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=invested, acknowledge, Site, answered X-Spam-User: qpsmtpd, 3 recipients X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Oct 2017 13:47:41 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dzk1T-0000vv-DF from Thomas_Schwinge@mentor.com ; Wed, 04 Oct 2017 06:47:39 -0700 Received: from tftp-cs (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.224.2; Wed, 4 Oct 2017 06:47:38 -0700 Received: by tftp-cs (Postfix, from userid 49978) id 963CDC21A2; Wed, 4 Oct 2017 06:47:38 -0700 (PDT) From: Thomas Schwinge To: , Gerald Pfeifer CC: Carlos O'Donell , Richard Biener , , , Subject: Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc. In-Reply-To: <87tvzuk29t.fsf@euler.schwinge.homeip.net> References: <87zi9oj8rl.fsf@euler.schwinge.homeip.net> <347AE883-971C-447C-AB07-43F7F70F25D3@gmail.com> <4056e466-3055-455b-9922-55497d21fd80@redhat.com> <87tvzuk29t.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/25.2.1 (x86_64-pc-linux-gnu) Date: Wed, 04 Oct 2017 13:47:00 -0000 Message-ID: <87376zja8d.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-10/txt/msg00004.txt.bz2 Hi! Ping. On Fri, 22 Sep 2017 20:37:50 +0200, I wrote: > On Thu, 21 Sep 2017 12:18:39 -0600, Carlos O'Donell w= rote: > > On 09/21/2017 11:56 AM, Richard Biener wrote: > > > On Thu, 21 Sep 2017 11:38:29 -0600, Carlos O'Donell wrote: > > > > On 09/21/2017 10:50 AM, Thomas Schwinge wrote: > > > > > So my question is, if I've gotten a patch reviewed by someone who= is not > > > > > yet ;-) familiar with that new process, and I nevertheless want to > > > > > acknowledge their time invested in review by putting "Reviewed-by= " into > > > > > the commit log, is it fine to do that if the reviewer just answer= ed with > > > > > "OK" (or similar) instead of an explicit "Reviewed-by: NAME " > > > > > statement? > > > > You should instead ask the author to give their "Reviewed-by:" and = point > > > > out what the Reviewed-by statement means. > > > >=20 > > > > > That is, is it fine to assume that our current patch review's sta= ndard > > > > > "OK" (or similar) answer matches the more formal "Reviewer's stat= ement of > > > > > oversight"? > > > >=20 > > > > Not yet. > > >=20 > > > I think given an OK from an official reviewer entitles you to commit > > > it indeed IS matching the formal statement. It better does... >=20 > I certainly understand your rationale, and do agree to that -- yet, I can > see how somebody might get offended if turning a casual "OK" into a > formal "Reviewed-by: NAME ", so... >=20 > > Isn't it better to be explicit about this; rather than assuming? >=20 > ..., yeah, that makes sense. >=20 > Anyway: aside from starting to use them, we should also document such new > processes, so we might do it as follows, where I had the idea that the > *submitter* 'should encourage the reviewer to "earn" this > acknowledgement'. >=20 > Gerald, OK to commit? If approving this patch, please respond with > "Reviewed-by: NAME " so that your effort will be recorded. See > . There you go. ;-) >=20 > Index: htdocs/contribute.html > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v > retrieving revision 1.87 > diff -u -p -r1.87 contribute.html > --- htdocs/contribute.html 9 Apr 2015 21:49:31 -0000 1.87 > +++ htdocs/contribute.html 22 Sep 2017 18:20:04 -0000 > @@ -23,7 +23,7 @@ contributions must meet:

>
  • Testing Patches
    • >
  • Documentation Changes
    • >
  • Web Site Changes
    • > -
  • Submitting Patches
    • > +
  • Preparing Patches
    • >
  • Announcing Changes (to our Users)
    • > >=20=20 > @@ -164,7 +164,7 @@ file" mode of the validator.

    >

    More about our web pages.

    >=20=20 >=20=20 > -

    Submitting Patches

    > +

    Preparing Patches

    >=20=20 >

    Every patch must have several pieces of information, before = we > can properly evaluate it:

    > @@ -257,6 +257,71 @@ bzip2ed and uuencoded or encoded as a acceptable, as long as the ChangeLog is still posted as plain text. >

    >=20=20 > + > +

    Acknowledge Patch Review

    > + > +

    Patch review often is a time-consuming effort. It is appreciated to > + acknowledge this in the commit log. We are adapting > + the Reviewed-by: tag as established by the Linux kernel p= atch > + review process.

    > + > +

    As this is not yet an established process in GCC, you, as the submitt= er, > + should encourage the reviewer to "earn" this acknowledgement. For exa= mple, > + include the following in your patch submission:

    > + > +
    > +

    If approving this patch, please respond with "Reviewed-by: NAME > + <EMAIL>" so that your effort will be recorded. See > + <https://gcc.gnu.org/contribute.html#patches-review>. > +

    > +
    > + > +

    For reference, reproduced from > + the Linux > + kernel 4.13's Documentation/process/submitting-patches.rst: > +

    > + > +
    > +

    Reviewed-by: [...] indicates that the patch has been revie= wed > + and found acceptable according to the Reviewer's Statement:
    > +
    > +Reviewer's statement of oversight
    > +
    > +By offering my Reviewed-by: tag, I state that:
    > +
    > + (a) I have carried out a technical review of this patch to > + evaluate its appropriateness and readiness for inclusion [...]. > +
    > +
    > + (b) Any problems, concerns, or questions relating to the patch > + have been communicated back to the submitter. I am satisfied > + with the submitter's response to my comments. > +
    > +
    > + (c) While there may be things that could be improved with this > + submission, I believe that it is, at this time, (1) a > + worthwhile modification [...], and (2) free of known > + issues which would argue against its inclusion. > +
    > +
    > + (d) While I have reviewed the patch and believe it to be sound, I > + do not (unless explicitly stated elsewhere) make any > + warranties or guarantees that it will achieve its stated > + purpose or function properly in any given situation. > +
    > +
    > +A Reviewed-by: tag is a statement of opinion that the patch is = an > +appropriate modification [...] without any remaining serious > +technical issues. Any interested reviewer (who has done the work) can > +offer a Reviewed-by: tag for a patch. This tag serves to give = credit to > +reviewers and to inform maintainers of the degree of review which has be= en > +done on the patch. Reviewed-by: tags, when supplied by reviewe= rs known to > +understand the subject area and to perform thorough reviews, will normal= ly > +increase the likelihood of your patch getting [...] [approved]. > +

    > + > +

    Submitting Patches

    > + >

    When you have all these pieces, bundle them up in a mail message and > send it to the appropriate mailing list(s). > (Patches will go to one or more lists depending on what you are >=20 > (I have not yet spent much time on verifying the HTML, or formatting > tweaks.) Gr=C3=BC=C3=9Fe Thomas