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=-0.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 20731C04AB1 for ; Thu, 9 May 2019 14:11:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E2CDC21479 for ; Thu, 9 May 2019 14:11:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726411AbfEIOLq (ORCPT ); Thu, 9 May 2019 10:11:46 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:50225 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726087AbfEIOLq (ORCPT ); Thu, 9 May 2019 10:11:46 -0400 Received: from [85.235.16.11] (helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hOjlw-0008JK-0a for linux-spdx@vger.kernel.org; Thu, 09 May 2019 16:11:44 +0200 Date: Thu, 9 May 2019 16:11:38 +0200 (CEST) From: Thomas Gleixner To: linux-spdx@vger.kernel.org Subject: Workflow Message-ID: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org 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. >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). 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. 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 :) 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? Thanks, tglx