Re: A fs-next branch

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, May 20, 2024 at 01:23:26PM +1000, Stephen Rothwell wrote:
> On Tue, 14 May 2024 23:57:36 +0100 Matthew Wilcox <willy@infradead.org> 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.

What we were hoping for was that you would merge together the vfs,
iomap, and various fs-specific trees (e.g., bcachefs, btrfs, ext4,
f2fs, xfs, etc.) together, and then publish it as "fs-next".

You could then use fs-next as something that would be merged into
linux-next instead of the component fs trees, so hopefully it wouldn't
be a significant amount of extra work for you.

As Willy stated, the advantages of having an official daily "fs-next"
tree is that multiple file system developers would be able to test the
same branch and compare notes when regressions are found.  And the
advantage of fs-next versus the full linux-next is that it reduces the
chances of tests getting blocked by non-fs-relevant changes.

Cheers,

					- Ted