From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23240 invoked from network); 13 Apr 2021 21:31:47 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 13 Apr 2021 21:31:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=Lgy6h1XfUJgOxl/TLQmqLolsIUYF8/aAZj9E7qEBcNM=; b=KoqBAdmvQiwZRgtPqghrnMHc0Y 8cu4W9QOH3MYfECYoB/2GYUh672UJdRZZpFVv4etOLmS8QTvnkvtFgWljb5LZeYU0MhkNDfBINfPs jagSjmxCE0sQluvpUdLd6nKBlsVpyWCPe9DxEW4rjZsrFlotaqln/Hso8EHxLk56T+ovdxi1I06Zw nBULyxsuy626x3lAEI+5HWMiLSTUxEWoVFIYFurJnY0K874M4sLwq7z4Jgf6T44r9+xlqJrfnTxcG ACKmOEZqcyNbJvKWdSlKyurPKdHXHFkK6A9F1syUIRMbLaWZ7vOVZBYqEPrPLh9m8lvfSaoRgYWJb 04lViNgQ==; Received: from authenticated user by zero.zsh.org with local id 1lWQdP-000L4D-2N; Tue, 13 Apr 2021 21:31:47 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1lWQdA-000KqV-TI; Tue, 13 Apr 2021 21:31:33 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailauth.nyi.internal (Postfix) with ESMTP id 5D84527C0054; Tue, 13 Apr 2021 17:31:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 13 Apr 2021 17:31:31 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekledgudeifecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesth hqmhdthhdtjeenucfhrhhomhepnfgrfihrvghntggvpgggvghljoiiqhhuvgiiuceolhgr rhhrhihvseiishhhrdhorhhgqeenucggtffrrghtthgvrhhnpeelvddtfeetjedufeethf eglefghfdttddvueevjeehiedtieduvdffgeejhefhveenucfkphepuddttddruddvrddu leekrdeggeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehlrghrrhihvhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduhedu keejjedtgedqudduledvjeefkeehqdhlrghrrhihvheppeiishhhrdhorhhgsehfrghsth hmrghilhdrtghomh X-ME-Proxy: Received: from [192.168.1.15] (pool-100-12-198-44.nycmny.fios.verizon.net [100.12.198.44]) by mail.messagingengine.com (Postfix) with ESMTPA id E78B61080069; Tue, 13 Apr 2021 17:31:30 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Subject: Re: Patch bumping (was Re: Feature Patch: Use completion to view parameter values) From: =?utf-8?Q?Lawrence_Vel=C3=A1zquez?= In-Reply-To: <20210413133524.GJ6819@tarpaulin.shahaf.local2> Date: Tue, 13 Apr 2021 17:31:30 -0400 Cc: zsh-workers@zsh.org Content-Transfer-Encoding: quoted-printable Message-Id: <2EE1CCA0-E8C3-4A9F-898B-F823890EA58C@zsh.org> References: <20210413133524.GJ6819@tarpaulin.shahaf.local2> To: Daniel Shahaf X-Mailer: Apple Mail (2.3445.104.17) X-Seq: 48549 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: > On Apr 13, 2021, at 9:35 AM, Daniel Shahaf = wrote: >=20 > Marlon wrote on Mon, Apr 12, 2021 at 11:18:43 +0300: >> On 12 Apr 2021, at 00:24, Bart Schaefer = wrote: >>> 1. The patch has never been reviewed or discussed. >>> 2. The patch was reviewed and is acceptable, but was never applied. >>> 3. There was a discussion, but it ended without resolution. >>> 4. The patch was referred back to the author after review or = discussion. > =E2=8B=AE >>> I mention this mostly because I think the useful elapsed time before >>> "bumping" might be different in each case. In particular #4 seems >>> like it could be left considerably longer, unless the patch is = fixing >>> a serious bug or security issue. >>=20 >> I would suggest the following minimum wait times before bumping: >>=20 >> * To remind about an unresolved patch (not yet reviewed, not yet = responded to by author after review, not yet = accepted/rejected/committed, etc.): >> * security issues: 2 days >> * critical bug fixes: 1 week >> * all other patches: 2 weeks >> * Everything else: 1 month >=20 > I'm not sure what cases fall into "etc." and what cases fall into > "everything else", nor what would a "critical" bugfix be. "Everything else" seems like "anything not involving an unresolved patch", which is out of scope as far as I'm concerned. > How would differential delays affect your workflow? A uniform = criterion > (such as "Thread has been dormant for >5 days") should be easier to = apply. The uniform criterion is definitely easier. I'm open to giving certain patch discussions more room to breathe, but at the granularity of two classes (more urgent vs. less urgent) and not four or more. > Regarding your taxonomy, would it be accurate to say that in cases > A and B a submitted patch is awaiting resolution, whereas in case C = it's > generally a design question that's awaiting resolution? In A+B the > person in question is the patch submitter; in C the person in question > is probably a regular developer. That tracks with what I've seen, although in all cases there's at least one patch in flight. (After all, the role is "patch manager", not "discussion manager".) Type A also includes discussions wherein a contribution has been accepted but not yet committed. Many type C discussions are just a committer saying "I'm thinking about committing this, what does everyone think?" and then waiting on any feedback, from nitpicks to overarching design critique. > (Aside: Note the terminology: "developer", not "committer", since in > general, distinctions between people who do and don't have commit = access > shouldn't be made, except when it's necessary to actually invoke =C2=ABg= it > push=C2=BB.=C2=B9) Sure, but commit access is relevant to patch discussions involving noncommitting contributors (types A and B) because the commit step is often the only thing holding things up. > Regarding the magic numbers, I think one month is too long for case B > (cf. my remarks today in workers/48526). We don't want to bump _too_ > soon either, but I'd aim for something on the order of a week (for the > first ping, again as per 48526). "Once a week for patches =E2=89=A56 = days old" > achieves that, as would, say, "at least 48 weekend hours and at least > 72 weekday hours". This effectively retains my current policy for types A and B. I'd be fine with this, but we haven't heard Bart's rationale for longer intervals. > No comment from me on case C. Should I continue bumping developer-only patch discussions at all? If so, I'm inclined to let them simmer for longer -- perhaps a month (as per workers/48516). I feel pretty pesky basically reminding committers to commit their own patches, but everyone forgets things now and then. Is it helpful or annoying? --=20 vq=