From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E471C04A6B for ; Fri, 10 May 2019 09:06:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D233E2175B for ; Fri, 10 May 2019 09:06:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557479165; bh=4hVZCQVZa2xa7vyK+uickIU8j3zh15p0JI2qJJQG0Nk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=Fb1RTqI8+d6pqzAAtfLEHCuwMPI65vEHrAOtz9LIlWosDbBKy7k4ODLsDXbtBmxaW XtoJyzpfJ9rq7kekcbdWTSX3d9jt3Kbpd4N9VA6d38vry3Q0qOlNnIOzxZv8MekiPs wkVEtzEOojSa0iTTzvWY3fSTyGcZqDaZUyTmPo10= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727009AbfEJJGF (ORCPT ); Fri, 10 May 2019 05:06:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:44636 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726992AbfEJJGF (ORCPT ); Fri, 10 May 2019 05:06:05 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8B95520989; Fri, 10 May 2019 09:06:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557479164; bh=4hVZCQVZa2xa7vyK+uickIU8j3zh15p0JI2qJJQG0Nk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kwJDLMjbzcXvBzjWy1dN4V1a4/2OGMvSfS6zTLods8LXVF71+DiJy+9pS39r+oFXF sKdiHt6fteH29hqn8/ufZzVeVfB4L4HImKBbaXLTvsAczn3oh2HKXb35/vB6y/iLfQ G/+mo9bVODcnr8fdSKL+dLtfCKEX3sp6ktZjXfD4= Date: Fri, 10 May 2019 11:06:01 +0200 From: Greg KH To: Thomas Gleixner Cc: linux-spdx@vger.kernel.org Subject: Re: Workflow Message-ID: <20190510090601.GB7058@kroah.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org On Thu, May 09, 2019 at 04:11:38PM +0200, Thomas Gleixner wrote: > Folks, > > we should ASAP agree on a workflow for going through those 504 > patches. Here is my proposal: > > 1) Use the one patch per identified pattern approach as demonstrated > with the first 4. > > 2) Focus the review on the 'pattern -> SPDX id' conclusion > > 3) Trust the automated patcher to do the right thing. Sounds good to me. > From my experience with this, it's the most sensible way, as it makes it > scalable. > > Versus trusting the patcher: I'm surely spending time on looking at the > actual changes, but that's also massively based on automated analysis which > exposes only unexpected changes and does not force me to stare at 20k+ > patched instances. > > If we can agree on the above, then I'd like to send out batches of N > patches, where N would be something in the range of 10-25. These patches > are basically changelog only because quite some of the patches are too long > for posting on the list. They surely will contain a git URL so you can look > at the actual file changes as well (if you are masochistic enough). I like longer batches, as I'm used to them, but 20-25 is fine. > Ideally we get a quick feedback (OK/NOK) for each patch in a batch. The OK > should be preferrably in the form of a 'Reviewed-by: Your Name ' > tag. We'll mention in the changelog that the Review is limited to the > pattern -> SPDX id conclusion and does not cover the actual file level > changes. I'll take the blame when then patcher gets it wrong :) > > If a patch is deemed NOK we don't have to sort it out immediately. We can > post pone it and handle it on the side so the queue is not held up. > > Once a patch has collected Reviewed-by tags we would apply it to a > repository and send it in batches to Linus. Sounds reasonable. > If a batch is consumed (except for the NOK parts) the next batch would be > posted. Assumed we can handle 10 'pattern -> SPDX id' reviews per day, that > would take ~10 weeks. Which is quite some time when we want to be halfways > SPDX clean for the next LTS kernel. So I rather see larger batches > processed faster :) You should be able to send multiple batches at a time, right? But 10 weeks isn't all that bad, I would shoot to get these all into the 5.4 kernel, so we can be done with it :) > Any opinions on the size of the batches and how long it will take to get > the reviews done or any other suggestions for a workable solution? Normally I just wait 2 weeks for tiny patches, or one kernel release cycle. If no objections, then I merge to a tree that Linus can pull from. As a good example of this, I have some debugfs x86 patches that I posted a while ago, no maintainer said anything, or took them into their own tree, so I'll just merge them to a local tree to be sent off for 5.3-rc1 :) thanks, greg k-h