From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id FDWyAVUr0V+eHgAAWB0awg (envelope-from ) for ; Wed, 09 Dec 2020 14:53:57 -0500 Received: by simark.ca (Postfix, from userid 112) id ED1551F0A9; Wed, 9 Dec 2020 14:53:56 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A93FB1E590 for ; Wed, 9 Dec 2020 14:53:55 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2B7033850409; Wed, 9 Dec 2020 19:53:55 +0000 (GMT) Received: from orcam.me.uk (unknown [IPv6:2001:4190:8020::2]) by sourceware.org (Postfix) with ESMTP id 4124E3850409 for ; Wed, 9 Dec 2020 19:53:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4124E3850409 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux-mips.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=macro@linux-mips.org Received: from bugs.linux-mips.org (eddie.linux-mips.org [IPv6:2a01:4f8:201:92aa::3]) by orcam.me.uk (Postfix) with ESMTPS id DCFD42BE0EC; Wed, 9 Dec 2020 19:53:50 +0000 (GMT) Date: Wed, 9 Dec 2020 19:53:48 +0000 (GMT) From: "Maciej W. Rozycki" To: Simon Marchi Subject: Re: [PATCH 1/4] gdb: make discrete_position return optional In-Reply-To: <2df9aeac-be70-8704-e1c1-fd108fe50c51@polymtl.ca> Message-ID: References: <20201123162120.3778679-1-simon.marchi@efficios.com> <20201123162120.3778679-2-simon.marchi@efficios.com> <20201206053835.GC321750@adacore.com> <11f410ad-f939-5668-9566-00287a3a891d@efficios.com> <20201208030632.GF3202@adacore.com> <2df9aeac-be70-8704-e1c1-fd108fe50c51@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Simon Marchi , Simon Marchi via Gdb-patches , Joel Brobecker Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On Wed, 9 Dec 2020, Simon Marchi wrote: > > FWIW at we have a working > > instance of patchwork too that can be used to track own and other people's > > submissions, which also has been recently brought up to date as far as the > > engine is concerned, thanks to people using it actively for the glibc > > project. They've even set up a weekly meeting recently to review patches: > > . That might > > be something to consider I believe for patch management. > > Yes, I think we should use it! > > But our previous experience with Patchwork is that it's a lot of work to > manage patches to keep Patchwork in a good state. When you send a v2, v3, > v4 of a series, it creates new patches, and someone needs to manually go > set the older ones as "Superseded". And when then patches get merged, > someone needs to go mark them as "Merged" so they go away. > > Is this how it still works? > > If Patchwork could do that somewhat automatically and reliably (say, by > relying on same the Change-Ids as Gerrit uses), I think it would be > wonderful. This is a known issue glibc people have been actively working on: and given that we share the instance of patchwork once it has been done it will either work automatically for us too, or it should be easy to adapt. Also I guess someone from our side might as well step in and participate in the effort. Maciej