On Wed, Apr 17, 2024 at 4:12 PM Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > On Tue, Apr 16, 2024 at 09:34:47PM +0100, Matthew Wilcox wrote: > > On Tue, Apr 16, 2024 at 02:04:14PM -0400, Josef Bacik wrote: > > > I would like to propose we organize ourselves more akin to the other > > > large subsystems. We are one of the few where everybody sends their > > > own PR to Linus, so oftentimes the first time we're testing eachothers > > > code is when we all rebase our respective trees onto -rc1. I think > > > we could benefit from getting more organized amongst ourselves, having > > > a single tree we all flow into, and then have that tree flow into Linus. > > > > This sounds like a great idea to me. As someone who does a lot of > > changes that touch a lot of filesystems, I'd benefit from this model. > > It's very frustrating to be told "Oh, submit patches against tree X > > which isn't included in linux-next". > > I think an even better starting point would just be (more) common test > infrastructure. We've already got fstests, what we need is a shared > cluster (two racks of machines?) that is dedicated to automated testing > on _any_ kernel filesystem. Yes - this can be very helpful. Although we have to deal with many types of non-Linux servers with cifs.ko (MacOS, Visuality, Windows, Azure, NetApp etc.) at least we have two Linux servers that could be used as test targets easily (e.g. with localhost mounts). A lot of what I struggle with though is how to sanely automate testing of pull requests to branches (as large projects like Samba) and the automated backports of fixes, and handle good automated collection of traces/logs/dmesg when tests fail. > I've got the code for this all ready to go, as soon as someone is > willing to pony up on hardware. > > That would mean people like Willy who are doing cross filesystem testing > would have a _lot_ less manual work to do, and having a cluster that > watches our git branches and kicks off tests when someone pushes (i.e. > what I already have, just on a bigger scale) would mean that we'd be > full test suite results back in 5-10 minutes after writing the code and > pushing. That sort of thing is amazing for productivity... no more > sitting around twiddling thumbs waiting for the evening test run... I agree ... -- Thanks, Steve
