Re: Workflow

[Greg KH <gregkh@linuxfoundation.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 <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.

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