From: Luis Chamberlain <mcgrof@kernel.org>
To: lsf-pc@lists.linux-foundation.org
Cc: amir73il@gmail.com, a.manzanares@samsung.com,
chandan.babu@oracle.com, jlayton@kernel.org,
josef@toxicpanda.com, Pankaj Raghav <p.raghav@samsung.com>,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org
Subject: LSF/MM/BPF BoF: pains / goods with automation with kdevops
Date: Sat, 28 Jan 2023 21:34:56 -0800 [thread overview]
Message-ID: <Y9YFgDXnB9dTZIXA@bombadil.infradead.org> (raw)
More suitable towards a BoF as I don't *think* a larger audience would be
interested. At the last LSF during our talks about automation it was suggested
we could share a repo and go to town as we're all adults. That's been done:
https://github.com/linux-kdevops/kdevops
At ALPSS folks suggested maybe non-github, best we can do for now is
gitlab:
https://gitlab.com/linux-kdevops/kdevops
There's been quite a bit of development from folks on the To list. But
there's also bugs even on the upstream kernel now that can sometimes erk us.
One example is 9p is now used to be able to compile Linux on the host
instead of the guests. Well if you edit a file after boot on the host
for Linux, the guest won't see the update, so I guess 9p doesn't update
the guest's copy yet. Guests just have to reboot now. So we have to fix that
and I guess add 9p to fstests. Or now that we have NFS support thanks to
Jeff, maybe use that as an option? What's the overhead for automation Vs 9p?
We dicussed sharing more archive of results for fstests/blktests. Done.
What are the other developer's pain points? What would folks like? If
folks want demos for complex setups let me know and we can just do that
through zoom and record them / publish online to help as documentation
(please reply to this thread in private to me and I can set up a
session). Let's use the time at LSF more for figuring out what is needed
for the next year.
Luis
next reply other threads:[~2023-01-29 5:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-29 5:34 Luis Chamberlain [this message]
2023-05-03 20:02 ` LSF/MM/BPF BoF: pains / goods with automation with kdevops Jeff Layton
2023-05-03 20:06 ` Adam Manzanares
2023-05-04 5:59 ` Amir Goldstein
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=Y9YFgDXnB9dTZIXA@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=a.manzanares@samsung.com \
--cc=amir73il@gmail.com \
--cc=chandan.babu@oracle.com \
--cc=jlayton@kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=p.raghav@samsung.com \
/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;
as well as URLs for NNTP newsgroup(s).