From: "Darrick J. Wong" <djwong@kernel.org>
To: Eryu Guan <guaneryu@gmail.com>
Cc: fstests@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
Eric Sandeen <sandeen@sandeen.net>,
Amir Goldstein <amir73il@gmail.com>
Subject: Re: maintainership of fstests
Date: Mon, 21 Mar 2022 15:13:36 -0700 [thread overview]
Message-ID: <20220321221336.GM8241@magnolia> (raw)
In-Reply-To: <Yjdmj0lVqCbbbjW8@desktop>
On Mon, Mar 21, 2022 at 01:38:23AM +0800, Eryu Guan wrote:
> Hi folks,
>
> It's almost 6 years since I've taken the maintainership of fstests, and
> I tried my best to keep the pace of weekly update, or at least bi-weekly
> update due to something like public holidays.
>
> But it's been a month since last fstests update due to my personal
> urgent issues, and some patches got no review for more than one month.
> So I think it's time to re-consider the maintainership of fstests.
>
> I will have less spare time in the foreseeable future, as I have to
> spend more time on my family, so it's hard to keep the weekly update
> pace. And six years is a long time, I think it's time to have a new
> maintainer.
Thank you for your service for all that time! :)
> Or we could go to the group-maintain way? As Darrick mentioned before
> (for xfs not fstests, if I recall correctly). Then we need a new primary
> maintainer :)
>
> What do you think?
Splitting responsibility for maintenance doesn't seem like a huge step
to me -- for fs-specific tests, we need the developers for that fs to
review test changes. Review for tests/generic/ can be done by the
fs{devel,*} community at large, much as it is done now.
The /difficult/ part, I think, is handling things like treewide
reorganizations, and integration testing the test suite. That, I think,
is what really requires a primary maintainer who has broader visibility
into what's going on.
That primary maintainer also has to have time to run a build-and-test
farm of all the major fstests clients (ext*, xfs, btrfs, overlay, nfs,
what else?) to make sure that new code doesn't break existing
filesystems' ability to test themselves.
Granted, (speaking only for XFS, probably btrfs, and maybe even ext*),
we seem to notice regressions pretty fast when we download the weekly
release, so I think the primary maintainer's focus probably ought to be
more towards the non-mainstream Linux filesystems.
Also: over the past 6 years, I have /really/ enjoyed the fact that
fstests has small releases every 1-2 weeks as opposed to larger
infrequent drops. It's a relief not to have to chase a merge window
like I do for the kernel. Thank you a bunch for keeping that going!
--D
FYI: It's Spring Break here in the US, so you might not get much of a
response for a week or two.
>
> Thanks,
> Eryu
>
> P.S.
> I'll keep the maintainer role and do the review & update as usual until
> all things settle down.
next prev parent reply other threads:[~2022-03-21 22:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-20 17:38 maintainership of fstests Eryu Guan
2022-03-21 5:51 ` Zorro Lang
2022-03-21 16:19 ` Zorro Lang
2022-04-04 15:36 ` Eric Sandeen
2022-04-04 16:15 ` Zorro Lang
2022-04-05 0:57 ` Darrick J. Wong
2022-04-05 9:04 ` Ritesh Harjani
2022-04-08 7:57 ` Boyang Xue
2022-04-10 16:24 ` Eryu Guan
2022-04-10 18:13 ` Darrick J. Wong
2022-03-21 22:13 ` Darrick J. Wong [this message]
2022-04-10 16:15 ` Eryu Guan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220321221336.GM8241@magnolia \
--to=djwong@kernel.org \
--cc=amir73il@gmail.com \
--cc=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=guaneryu@gmail.com \
--cc=sandeen@sandeen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox