On Mon, May 20, 2024 at 01:23:26PM +1000, Stephen Rothwell wrote: > Hi Willy, > > Sorry for the slow response. No problem; I figure you get one week off every ten weeks or so ... > On Tue, 14 May 2024 23:57:36 +0100 Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > At LSFMM we're talking about the need to do more integrated testing with > > the various fs trees, the fs infrastructure and the vfs. We'd like to > > avoid that testing be blocked by a bad patch in, say, a graphics driver. > > > > A solution we're kicking around would be for linux-next to include a > > 'fs-next' branch which contains the trees which have opted into this > > new branch. Would this be tremendously disruptive to your workflow or > > would this be an easy addition? > > How would this be different from what happens at the moment with all > the separate file system trees and the various "vfs" trees? I can > include any tree. As I understand the structure of linux-next right now, you merge one tree after another in some order which isn't relevant to me, so I have no idea what it is. What we're asking for is that we end up with a branch in your tree called fs-next that is: - Linus's tree as of that day - plus the vfs trees - plus xfs, btrfs, ext4, nfs, cifs, ... but not, eg, graphics, i2c, tip, networking, etc How we get that branch is really up to you; if you want to start by merging all the filesystem trees, tag that, then continue merging all the other trees, that would work. If you want to merge all the filesystem trees to fs-next, then merge the fs-next tree at some point in your list of trees, that would work too. Also, I don't think we care if it's a branch or a tag. Just something we can call fs-next to all test against and submit patches against. The important thing is that we get your resolution of any conflicts. There was debate about whether we wanted to include mm-stable in this tree, and I think that debate will continue, but I don't think it'll be a big difference to you whether we ask you to include it or not?
