From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5546 invoked by alias); 11 Feb 2019 16:27:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 5537 invoked by uid 89); 11 Feb 2019 16:27:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=2.1 required=5.0 tests=BAYES_00,BODY_8BITS,GARBLED_BODY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=presentation, HContent-Transfer-Encoding:8bit X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Feb 2019 16:27:15 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x1BGMf5T031208; Mon, 11 Feb 2019 10:22:48 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x1BGMWn0031206; Mon, 11 Feb 2019 10:22:32 -0600 Date: Mon, 11 Feb 2019 16:27:00 -0000 From: Segher Boessenkool To: =?utf-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: Joseph Myers , gcc-patches Subject: Re: Make clear, when contributions will be ignored Message-ID: <20190211162229.GR14180@gate.crashing.org> References: <25a0e5620b1e8a7a831ae9660c988f5dd98aa7dd.camel@aegee.org> <20181205171121.GQ3803@gate.crashing.org> <0990b8acd4cc08f74c1bf314851a113711dbfa04.camel@aegee.org> <20190206124401.GO14180@gate.crashing.org> <20190210205616.GJ14180@gate.crashing.org> <120af439a98fc4160e684fca11fc63715e20ca93.camel@aegee.org> <20190211135742.GO14180@gate.crashing.org> <5da63d0daa0f4b086f07d48a5e82240bb9a8f425.camel@aegee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5da63d0daa0f4b086f07d48a5e82240bb9a8f425.camel@aegee.org> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00775.txt.bz2 On Mon, Feb 11, 2019 at 02:16:27PM +0000, Дилян Палаузов wrote: > Hello Segher, > > my question was how do you propose to proceed, so that a no-reminders-for-patches-are-necessary-state is reached. > > There is no relation with having infinite time or dealing with high-cost low-profit patches. > > Previously I raised the quesion, whether automating the process for sending reminders, is a good idea. This saves time > of people to write reminders. But that would be "optimising" exactly the wrong thing! The choke point is patch review. So you should make it easier to review a patch, instead of making it easier to send in more patches. Your complaint is that many patches are sent in but then not reviewed, or not reviewed for a long while, after all. Easy to review patches are of course first and foremost patches that do the correct thing. But also they need to clearly say what they fix (and how), how the patch was tested, and they should often contain testcases for the testsuite. Easy to review patches usually use the same style and presentation as all other easy to review patches. Segher