Re: Collaborating updates of kdevops xfstests repo

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On Thu, Jul 21, 2022 at 10:59:48AM -0400, Theodore Ts'o wrote:
> On Thu, Jul 21, 2022 at 07:46:08AM -0700, Luis Chamberlain wrote:
> > If you look fstests has no release tags. Long term I think it would be
> > wonderful if we strive for that...
> 
> Since May, Zorro has started providing release tags --- it's tagged
> when he pushes a batch to for-next, and so far there hasn't been any
> changes between when a batch of updates get promoted from for-next to
> the master branch.
> 
> % git tag -l | grep ^v2022
> v2022.05.01
> v2022.05.08
> v2022.05.15
> v2022.05.22
> v2022.05.29
> v2022.06.05
> v2022.06.12
> v2022.06.26
> v2022.07.03

Fantastico.

> So if you want stability, you can wait until after the tag has been
> promoted to the master branch.  I've using the for-next branch for
> xfstests-bld, since I'm also doing development work for xfstests, and
> before I release an prebuilt image for kvm-xfstests or gce-xfstests,
> I've done a full sanity check run on at least ext4, xfs, btrfs, and
> f2fs.  And aside from a relatively rare hiccups, I've found for-next
> to be plenty stable enough for me.

This still begs the question of what can we count on for a tag, or if
want more.

> Of course, it's a bit easier for me, since I've explicitly *not* been
> promising that a reliable set of baseline configs that can be used for
> drive-by testers.

Git subtrees uses of kdevops can keep their own deltas / own fstests git
trees, etc. It was designed with that in mind.

> OTOH, last I checked, kdevops hasn't published new
> baselines since 5.17, which IMHO is way too old for drive-by testers
> who need to test patches meant for upstream submission anyway...

This is because of building confidence in a baseline on kdevops is done
first by striving for 100 consecutive runs of fstest and/or blktests
without failure and we lacked one for more recent kernels for a while.
Building confidence takes a while, but I consider it technical debt.

With a baseline with high confidence, it easy to bump one kernel
release, as the effort typically is just verifying prior known failures
(the status quo goes on) and picking up new ones. There would be high
confidence that these new failures are also regressions.

  Luis



[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux