On Thu, Oct 18, 2018 at 8:32 PM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Oct 18, 2018 at 02:24:40PM -0500, Major Hayden wrote:
Hello there,
I am working on a project at Red Hat where we do quick testing on patches for internal kernels before they merge. The goal is to catch bugs or issues before they merge into kernel trees and avoid situations where kernels need time-consuming bisects when lots of patches are merged at once. We aim to put valuable feedback into a kernel developer's inbox within four hours.
Yeah!
<snip>
We would love to bring this to upstream kernel repositories and we thought that linux-stable might be a good place to start. The developer/maintainer experience would look something like this:
- Developer submits a patchset
- Those patches end up in Patchwork
- We pull patches from patchwork, compile kernels, and test them
- We reply to the thread on the mailing list with a brief set of results (one time per patchset)
Developers do not need to change any existing workflows. We gather the patches, test them, and reply in the appropriate place.
Note that not all kernel mailing lists use Patchwork, but I guess you can always subscribe your own internal copies of it to the lists, right?
And also, we do not always send patches. We only send patches when it needs a backport, otherwise we will just mail Greg with the SHA that needs to be added to the tree.
Is this something that the linux-stable community and maintainers would find valuable? If so, feel free to ask any questions about our process and we can go over any of those parts in more detail. If not, please let me know anyway! Our team is always looking for ways to improve. :)
You can just go off of my email announcements for the -rc releases and do testing on that. That would be a great first step, and if you can not automatically detect this, I can add you to the email announcement if you want to trigger off of that.
Also you could watch the linux-stable-rc git tree for updates, that will be updated at -rc announcement time, and at other "time to take a break" moments in my development cycle.
Or alternatively, you can also monitor the stable-queue repo. I usually check the stable-queue repo, apply the patches to my personal tree before doing or testing anything.