From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81300 invoked by alias); 7 Dec 2018 10:55:22 -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 81169 invoked by uid 89); 7 Dec 2018 10:55:21 -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,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=organizations, aim, H*f:sk:25a0e56, thinks 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; Fri, 07 Dec 2018 10:55:19 +0000 Authentication-Results: mail.aegee.org/wB7AtBo4024503; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1544180113; i=dkim+MSA-tls@aegee.org; r=y; bh=451QBdrIBeJi6h3aokbbqmSEotaUVXNGNKllNkgX4Ek=; h=Subject:From:To:Date:In-Reply-To:References; b=khB34Xr5AKtukUOVEJAZ4pTR76JhXNnWzwpmEQiffEOVzbZ62ur4qf+cXl2pP+1V9 bS3ce5OJLIpNgea3WYlkQoYhV1VUMOCcbmh8vggI4oFk9CLznuJXhggSfofFx0xXmu UlsT7zwCRRB+iBqdEm98wr/lHE1f/p4kT3Vnxt4Rn0FAmecIoC06t4pnqBTBTuQX6J z+gwX7rAsQvNzlbuHxHz7g76rAlBUaaeFrspl3SxkcBX1tLIgH0aaWm+BnHNa1qQkr m3E1MQvLnVPvw3bdC1tDRq1ZLUXNCzY+wIULjGVARsyXIXv5D9PZr+NwZo2FZbFJ7y eKpHMfJ3zI/KSBMaEaj3VRFhUZUYfD2BQ/OCoAqDDtrb4IEuMdxSQXSnVjPGhiFxQj 2Rbdmb6XRnWi48O4RouXqp0IjEsyrC8G/f2mE6AddlCeaSazKpYZB7jan+RfkxlqFG nqoFeDWFtmMFmOiLT/TYToa+wNfkzwqbTPsg1R8R21dON4ie18QhLJ3VvwYoqA3Sfg kJenkwjmnN60VI3xrXiggvHtCBxUYVEReuLoJhqFtzDMDhXinA+6fXNJXDrZPyIWPh pf57VLaejC1fTVK+JG7HLxU1kMQ3dTPgqJLTHHqFTxmNGCLDG7t1j0geblVNbt0H2n iET+7aBsxnnAMQpOZutl5kks= Authentication-Results: mail.aegee.org/wB7AtBo4024503; dkim=none Received: from Tylan (37-219-194-104.nat.bb.dnainternet.fi [37.219.194.104]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id wB7AtBo4024503 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 7 Dec 2018 10:55:12 GMT Message-ID: <0990b8acd4cc08f74c1bf314851a113711dbfa04.camel@aegee.org> 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: gcc-patches Date: Fri, 07 Dec 2018 10:55:00 -0000 In-Reply-To: References: <25a0e5620b1e8a7a831ae9660c988f5dd98aa7dd.camel@aegee.org> <20181205171121.GQ3803@gate.crashing.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00442.txt.bz2 Hello, will it help, if Bugzilla is reprogrammed to send automatically weekly reminders on all patches, that are not integrated yet? Will lt help, if I hire myself to integrate the patch, or shall I rather hire somebody to send reminders? If something can be done after sending a reminder, then it can be arranged also without reminders. In particular, dealing with reminders is avoidable extra work. Whether people are paid or not, does not change on the subject very much. I have experienced organizations, where people are not paid and they manage to tackle everything. I have seen organizations where people are paid and they do not get the management right. I am not speaking about having some strict time to get a response, but rather to ensure an answer in reasonable time. No answer in reasonable time is the same as ignorance — the subject of this thread. The patch I proposed on 27th Oct was first submitted towards GDB and then I was told to send it to GCC. Here I was told to sent it to GDB. What shall happen to quit the loop? In any case, if the common aim is to have a system where contributions do not get lost, then I’m sure the workflows can be adjusted to achieve this aim. Regards Дилян On Wed, 2018-12-05 at 17:37 +0000, Joseph Myers wrote: > On Wed, 5 Dec 2018, Segher Boessenkool wrote: > > > Patches are usually ignored because everyone thinks someone else will > > handle it. > > And in this case, it looks like this patch would best be reviewed first in > the GDB context - then once committed to binutils-gdb, the committer could > post to gcc-patches (CC:ing build system maintainers) requesting a commit > to GCC if they don't have write access to GCC themselves. I consider > synchronizing changes to such top-level files in either direction to be > obvious and not to need a separate review. >