From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24797 invoked by alias); 17 Feb 2019 17:00:46 -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 24412 invoked by uid 89); 17 Feb 2019 17:00:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: Yes, score=5.5 required=5.0 tests=BAYES_20,BODY_8BITS,GARBLED_BODY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_WEB,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=complaint, Hx-spam-relays-external:sk:ip-37-2, H*RU:sk:ip-37-2, H*r:sk:ip-37-2 X-HELO: mail.aegee.org Received: from mail.aegee.org (HELO mail.aegee.org) (144.76.142.78) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 17 Feb 2019 17:00:22 +0000 Authentication-Results: mail.aegee.org/x1HGxfsX017659; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1550422781; i=dkim+MSA-tls@aegee.org; r=y; bh=m6owK27IPFrGMy5S/q4+tOcTp7EBFJmKMY6OzYNZgvk=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=hOBdEOqFkGONwa52+J00+LrOs8YL8QhwqaRAAiRohjCCze6nXo9Hgmh3owIKzTc/S 5tvvJTNHZ64k9l46odT23ZeF297NsnfkeDVV6OaCM7cgTjmudM6rrHgx+Nh3JK7hlU RBEnf3hr5EFrdHZIw7Tf+lL7AJYQKDp7Xz/3jzcN5it+hTeiwQ1O8JV6vzqWMNFKNf kISe1Mbifxgy589HzG9oapJtbiiycFoLOGTl3K3QvQQdWQj7aRHUuYkKN1r4qEIpOM 4LDjEvtN7CqcxDSFl+LCAJmbHOzP1VI/BUkuirW/coNK8PbleOWQ/co4wB3CNDi+nJ w2CvrC5GjUW0sqgVVBKEv0hJgDoV5wJTFW1k2TExTsdnIg0JjrLKpTmKmFb8Y31yGd DDjRrvddj1OJjGnCVJXQj+39O6r0/Mgip/lJxkVlM/hIzhnXVznl/T2DrK39zUlygm PY/5zFHQQYx/qfnPUjm825Ti++I5CgB3VGow0qWM3NI1yIEMJblO0cCrPmTVzwfu78 XzVHrTIpcGvh3RGbdC7xziTTWF6mKiuz2hW+1l7mpeNX056wBxngm/FMQfBZvr/McN cppsI3VMARwT4fCLbxgTB/ND72UNCXxf67nsljWsl/31SWv1meqi2o+W9SB+bE1kfv otMPCodYXLjuRfUSOOL0gvys= Authentication-Results: mail.aegee.org/x1HGxfsX017659; dkim=none Received: from Tylan (ip-37-201-5-72.hsi13.unitymediagroup.de [37.201.5.72]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x1HGxfsX017659 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 17 Feb 2019 16:59:41 GMT Message-ID: Subject: Re: Make clear, when contributions will be ignored From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Segher Boessenkool Cc: Joseph Myers , gcc-patches Date: Sun, 17 Feb 2019 17:00:00 -0000 In-Reply-To: <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> <20190211162229.GR14180@gate.crashing.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.91 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg01403.txt.bz2 Hello Segher, your prompt answer is appreciated. As a matter of fact patches are not reviewed for whatever reason in reasonable time. My point is to reorgnize the approach in such a way, that sending reminders gets irrelevant (has no impact) and therefore not necessary. Currently priority is given to submitters who send reminders, irrespective of the properties a patch has. Regards Дилян On Mon, 2019-02-11 at 10:22 -0600, Segher Boessenkool wrote: > 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