Last year we covered the new process for backporting to XFS. There are still remaining pain points: establishing a baseline for new branches is time consuming, testing resources aren't easy to come by for everyone, and selecting appropriate patches is also time consuming. To avoid the need to establish a baseline, I'm planning on converting to a model in which I only run failed tests on the baseline. I test with gce-xfstests and am hoping to automate a relaunch of failed tests. Perhaps putting the logic to process the results and form new ./check commands could live in fstests-dev in case it is useful for other testing infrastructures. As far as patch selection goes, we should consider what the end goal looks like XFS backporting. One potential option would be to opt-in for AUTOSEL and for patches that cc stable, and use bots to automatically check for regressions on queued up patches - this would require a lot more automation work to be done and would also depend on the timelines of how long patches are queued before merged, how long the tests take to run, etc. As for testing resources, we are still looking for employers to sponsor testing, ideally in a way that anyone willing to contribute to stable testing can easily gain access to resources for quick ramp-up.
