Delegating fstests maintenance work (Was: Re: [PATCH 3/4] xfs/{422,517}: add missing killall to _cleanup())

Delegating fstests maintenance work (Was: Re: [PATCH 3/4] xfs/{422,517}: add missing killall to _cleanup())

[Amir Goldstein]

[+fsdevel]

>
> I swear I'll send all these some day, if I ever get caught up...
> Delegating LTS maintenance is a big help, but as it is I still can't
> stay abreast of all the mainline patchsets /and/ send my own stuff. :(

I have to repeat what I said in LSFMM about the LTP project and
what fstests could be like.

Companies put dedicated engineers to work as proactive LTP
maintainers. There is absolutely no reason that companies won't
do the same for fstests.

If only every large corp. that employs >10 fs developers will assign
a halftime engineer for fstests maintenance, their fs developer's
work would become so much more productive and their fs product
will become more reliable.

I think the fact that this is not happening is a failure on our part to
communicate that to our managers.

From my experience, if you had sent stuff like your fstests cleanups
to the LTP maintainers and ask for their help to land it, they would
thank you for the work you did and take care of all the testing
on all platforms and fixing all the code style and framework issues.

LTP maintainers constantly work on improving the framework and
providing more features to test writers as well as on converting old
tests to use new infrastructure.

Stuff like Dave's work on sorting up the cleanup mess or the groups
cleanup and groups speedup - all of those do not have to add load
to busy maintainers - life can be different!

Taking responsibility away from developers to deliver their own tests
is a slippery slope, but getting help and working together is essential
for offloading work from busy maintainers.

Thanks,
Amir.

Re: Delegating fstests maintenance work (Was: Re: [PATCH 3/4] xfs/{422,517}: add missing killall to _cleanup())

[Darrick J. Wong]

On Fri, Jun 24, 2022 at 07:49:29AM +0300, Amir Goldstein wrote:
> [+fsdevel]
> 
> >
> > I swear I'll send all these some day, if I ever get caught up...
> > Delegating LTS maintenance is a big help, but as it is I still can't
> > stay abreast of all the mainline patchsets /and/ send my own stuff. :(
> 
> I have to repeat what I said in LSFMM about the LTP project and
> what fstests could be like.
> 
> Companies put dedicated engineers to work as proactive LTP
> maintainers. There is absolutely no reason that companies won't
> do the same for fstests.
> 
> If only every large corp. that employs >10 fs developers will assign
> a halftime engineer for fstests maintenance, their fs developer's
> work would become so much more productive and their fs product
> will become more reliable.
> 
> I think the fact that this is not happening is a failure on our part to
> communicate that to our managers.

I'd enjoy that too; I'll bring it up the next time they start asking
about budgeting here (which means in 2 weeks).

> From my experience, if you had sent stuff like your fstests cleanups
> to the LTP maintainers and ask for their help to land it, they would
> thank you for the work you did and take care of all the testing
> on all platforms and fixing all the code style and framework issues.

Though to be fair -- a lot of the fstests changes backing up in
djwong-dev exist to enable testing of the online fsck feature.  This
whole year I've deprioritized sending any of those patches to
concentrate on writing the design documentation for online fsck[1].  Now
that I've submitted *that*, I'm hoping to start code review once I
convince a few people to grok the design doc.

So perhaps next week I'll resume the patchbombing that I've become
infamous for doing.

In the mean time, no objections to merging /this/ series.  The group
labelling is a little odd and I think that should be separate fix from
adding _require_freeze), but if zorro's ok with its present form then so
be it.

--D

[1] https://lore.kernel.org/linux-xfs/165456652256.167418.912764930038710353.stgit@magnolia/

> LTP maintainers constantly work on improving the framework and
> providing more features to test writers as well as on converting old
> tests to use new infrastructure.
> 
> Stuff like Dave's work on sorting up the cleanup mess or the groups
> cleanup and groups speedup - all of those do not have to add load
> to busy maintainers - life can be different!
> 
> Taking responsibility away from developers to deliver their own tests
> is a slippery slope, but getting help and working together is essential
> for offloading work from busy maintainers.
> 
> Thanks,
> Amir.