From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121655 invoked by alias); 14 Oct 2019 20:58:18 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 121599 invoked by uid 89); 14 Oct 2019 20:58:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=monitoring, luis, Luis, H*r:authenticated X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 14 Oct 2019 20:58:16 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id x9EKw6Gd006385 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Oct 2019 16:58:11 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca x9EKw6Gd006385 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1571086692; bh=9xj7jy5tdIrl5WXxS0nEv8S6H8RGG7NSLdJN9KTDbv0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kUm5uvvV4i8Lepw+fxpnvhftcVImC3D21HCXO+Na9H4dgF1y7jQV2axRqfxHET4vT W/0eFlgmOH/nrG4zwrNbg5KOg7TITbEpcdVmuaJW/PzUlmxR9bL/5TFE55b802TezW hA4E843+muwSgFLUAxqG47PRsWtqe+G/my35+cec= Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id D54421E4C2; Mon, 14 Oct 2019 16:58:06 -0400 (EDT) Subject: Re: [PATCH] gdb: remove unused includes from dwarf2read.c To: Luis Machado , Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20191013045218.3261363-1-simon.marchi@polymtl.ca> <1c1f820fa507243fd7a2096ec3eb2454@polymtl.ca> <83r23fie80.fsf@gnu.org> <2fc75879-f6a5-bb6a-afc5-dc1477375147@linaro.org> From: Simon Marchi Message-ID: Date: Mon, 14 Oct 2019 20:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <2fc75879-f6a5-bb6a-afc5-dc1477375147@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00384.txt.bz2 On 2019-10-14 2:02 p.m., Luis Machado wrote: > The transition to some better (restrictions may apply) patch reviewing > system is a good thing, but i agree we should think further about it. > Personally i think we should discuss and then decide on a date by which > we will fully transition to it. > > Otherwise there is the potential for confusion since people will have to > look into two different places for patches. People may review stuff on > gerrit and the mailing list at the same time. This split isn't great and > is prone to cause collision of suggestions due to reviewers not being > aware of each other. etc. I am thinking that having Gerrit send notifications on gdb-patches alleviates this problem, as people who monitor the mailing list will see the review comments very similarly as if the review was done by email (I understand the format of these notifications is not ideal at the moment, we got some good feedback already). And I expect people who use Gerrit to keep monitoring the list at well for email patches. Also, I expect that people will review patches using the system where the patch was posted, so I don't think there is much risk of reviewers not being aware of each other. To be honest, some people jumped on Gerrit a bit faster than I expected :). I expected to have more time to tweak it before it would be used "for real", but I think we can tweak it as we go. > Ideally we'd put gerrit up when it is fully configured and functional, > being able to merge patches automatically. Then only maintainers will be > able to +2 (approve) patches and verify contributors meet the legal > requisites as is already the case with mailing lists? The problem with this is that we would need to involve the binutils community as well, which we wanted to avoid initially. We can't push to the master branch on Gerrit while the binutils folks push to the master branch on Sourceware: the two master branches would diverge. So we would need to convince them to use Gerrit too (at least, they would need to push to the Gerrit remote and we would need to disable pushing to Sourceware). But once we are happy with using our Gerrit instance (hopefully we'll get there) and decide we keep it permanently, we can talk to the binutils community to see if they would accept at least to change their push URL to our Gerrit, which would allow us to "Submit" using the Gerrit interface. And if they want to use Gerrit for review too, why not. Simon