From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 334CE3858C62 for ; Mon, 26 Sep 2022 16:43:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 334CE3858C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-pl1-x631.google.com with SMTP id iw17so6792354plb.0 for ; Mon, 26 Sep 2022 09:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=2KuHXxNJH58RO5GibCuUnvL5dhWEogpgfDGeh+g4ClY=; b=R0wt2XVMq/N8Vz0zADxBvbkwfhcVwRIjSZJvSJtFrqkgr8ciu15li0l2Yx81tRtKzc NgLBqNry9YeqL+HwlCWtPjY7V5OyR4EzGc50oALgvHqAUvVHiJRRcwXXxQs7i2gmAgFB 75HN6MVMFnR4FB/xN6e96JmTAr6Kck+J3umWKKUESqRO5CdceYAaT9ihKyRdmvFbTkJc 6AUTIegwzFF7khWlwR1hg23G70TsrUwbYeuMOWGA3fHlwdD0BImu0j2XDSyBM8my5eq+ qb2LQLCWCwPzdD91C0XGtw3gIjIPzOM+OWWx7ogy1PvttCT7FlmqnER7hPFvPDRwO77V +pvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=2KuHXxNJH58RO5GibCuUnvL5dhWEogpgfDGeh+g4ClY=; b=OfdP77JLjSWBjTmGNLY5tkx/EEXdbM4VGDHb5+wyZBwarcT+A1hZ5z7A4404HoHLNu MAPr/S3Ir3AhigCjv/pvXXIuCYa02nG1d87mZGU3rlWoJV+7rVbfGBlUxbu5jeDkzpTa II6OFQHPMq8JR1q/zqQiDO5GEwM7YJA8BJtoTc6Du6daY3EHZUUgXOQxoqqNFuoo3YHC 6ZUJM6S3t/ketNk1g/mTE1RwQ3/Cy/YdwvNEMU8cbxey0xl+OvpjiCWv6L1t6xgEAOKZ 2Oy8A+1TrAujbmtB9F/IAkuCCooLx5uC39+YPSn+xtKnoOeLq5Mgjfbv2jyA/n0BUkiO cOVQ== X-Gm-Message-State: ACrzQf2MELuCgyV4kGVpIBtr3imoHPZmctm3Ti9vRYznsFIlXKyGUW8W aeFNIbZ7N/o5SzG/kOpw+/b1 X-Google-Smtp-Source: AMsMyM7J3CVhA/P2FqZjjPZ4qprYTnLSCVuZVNLN6bJFr0vU5Emxaply/u2RMitIdGwbTCTn2Iocjg== X-Received: by 2002:a17:90b:1e07:b0:202:bb50:1963 with SMTP id pg7-20020a17090b1e0700b00202bb501963mr37396493pjb.82.1664210580995; Mon, 26 Sep 2022 09:43:00 -0700 (PDT) Received: from takamaka.gnat.com ([184.69.131.86]) by smtp.gmail.com with ESMTPSA id z9-20020a655a49000000b0043941566481sm11076103pgs.39.2022.09.26.09.43.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Sep 2022 09:43:00 -0700 (PDT) Received: by takamaka.gnat.com (Postfix, from userid 1000) id B577B81CED; Mon, 26 Sep 2022 09:42:59 -0700 (PDT) Date: Mon, 26 Sep 2022 09:42:59 -0700 From: Joel Brobecker To: Simon Marchi via Gdb Cc: Bruno Larsen , Joel Brobecker Subject: Re: Proposal: Add review tags to patch review workflow. Message-ID: References: <453759b1-1ddf-1aff-a033-6183b84a4a4d@simark.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453759b1-1ddf-1aff-a033-6183b84a4a4d@simark.ca> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Just thinking out loud... > I completely agree with the proposal. I really like the fact that it > makes communication less ambiguous. Following some process (or changing > the process) can feel a bit heavy for long-timers, but I think it makes > things much clearer for newcomers. Speaking of ambiguous, one thing that we used to do well in the past but then kind of got worse was the subject prefix we used to use to indicate the status of a patch. In particular, we used to reserve certain keywords for that in the subject (e.g. "RFA" vs "PATCH", or "OB" for obvious, etc). We lost that part, not sure exactly when, but I suspect sometime when we transitionned to Git. Something else also that I have been feeling the last year or two is that I'm not sure people now explicitly confirm to the list when a patch is pushed. The reason I mention this is to show that perhaps we're getting back to the fact that our email reviewing system is still email-based. One way to address the various limitations is by adding more processes, as suggested here. This has the good property of being fairly cheap to discuss and implement, at the cost of a small added overhead. I don't have a strong opinion about it, either for or against (and given the amount of time I have to contribute anyway, I don't think I should have a say). With that said, I have a feeling that switching to a system designed to manage patch submissions and reviews, no matter imperfect, is going to solve a lot of the limitations of the current email-based system. So that's another option worth reviewing from time to time, I think. I understand that selecting, deploying and trying new review systems requires a fair amount of effort. But having seen the benefits of using several different such systems, I am convinced that the gains will be very much worth whatever the drawbacks of that system might be. > Assuming we will go through with this proposal, it will need to be > documented on the wiki so we can easily refer people to the procedure. > Probably the ContributionChecklist page? > > https://sourceware.org/gdb/wiki/ContributionChecklist > > Will you be able to take care of this when needed (do you have write > access to the wiki)? > > In the mean time, message to others: please let us know if you agree > with this, it's difficult to know we have the support of the community > if everybody silently agrees! -- Joel