linux-spdx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kate Stewart <kstewart@linuxfoundation.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-spdx@vger.kernel.org
Subject: Re: Workflow
Date: Thu, 9 May 2019 09:45:29 -0500	[thread overview]
Message-ID: <CAG_66ZRWMm7WA9fRm46EVsOsnBr5hLuXqkEv05M-0XbOLMmQRA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1905091542340.3139@nanos.tec.linutronix.de>

Hi Thomas,

On Thu, May 9, 2019 at 9:11 AM Thomas Gleixner <tglx@linutronix.de> 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.
>
> 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 <your@mail>'
> 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?

Grouping them in digestible sets, and organizing each patch around a
pattern makes sense to me.     +1

Kate

  reply	other threads:[~2019-05-09 14:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-09 14:11 Workflow Thomas Gleixner
2019-05-09 14:45 ` Kate Stewart [this message]
2019-05-09 21:56   ` Workflow Thomas Gleixner
2019-05-10  9:25     ` Workflow Allison Randal
2019-05-10 10:54       ` Workflow Thomas Gleixner
2019-05-10 11:02         ` Workflow Allison Randal
2019-05-10 13:01     ` Workflow Kate Stewart
2019-05-10 13:18     ` Workflow Bradley M. Kuhn
2019-05-10  9:06 ` Workflow Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAG_66ZRWMm7WA9fRm46EVsOsnBr5hLuXqkEv05M-0XbOLMmQRA@mail.gmail.com \
    --to=kstewart@linuxfoundation.org \
    --cc=linux-spdx@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).