From: Gustavo Padovan <gustavo.padovan@collabora.com>
To: "Mark Brown" <broonie@kernel.org>
Cc: "dan.j.williams" <dan.j.williams@intel.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"workflows" <workflows@vger.kernel.org>,
"linux-doc" <linux-doc@vger.kernel.org>,
"linux-kselftest" <linux-kselftest@vger.kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Donald Zickus" <dzickus@redhat.com>,
"kernelci lists.linux.dev" <kernelci@lists.linux.dev>
Subject: Re: Crediting test authors
Date: Thu, 31 Jul 2025 11:30:44 -0300 [thread overview]
Message-ID: <19860e47e60.2269bf19518594.1062927936810569203@collabora.com> (raw)
In-Reply-To: <aIVMPbZcmAvG9z2o@finisterre.sirena.org.uk>
Hello,
---- On Sat, 26 Jul 2025 18:44:29 -0300 Mark Brown <broonie@kernel.org> wrote ---
> On Fri, Jul 25, 2025 at 11:37:13AM -0700, dan.j.williams@intel.com wrote:
> > Jakub Kicinski wrote:
>
> > > So a tag would be ideal. But it's a hard nut to crack. Best I can come
> > > up with would be:
>
> > > Reproducer: test.case.path # 001122aabb (optimal) commit of the test case
>
> > That's true, more than a few times I have had distro folks reach out to
> > ask "how do I verify this backport" and end up manually pointing to the
> > new unit test that backstops a fix.
>
> > Although, from that tag I would not know where to get the commit. Maybe:
> >
> > Test: <git url>
> >
> > ...as a new Link: type?
>
> It seems like there's some overlap here with the work that people have
> been intermittently trying to do on test cataloging, eg:
>
> https://lore.kernel.org/workflows/CAK18DXYitS7hL1mA3QsPLmW9-R0q6Kin0C5Uv9fj=uS90WSnxA@mail.gmail.com/
>
> That's been approached more from the "what tests should I run?" end of
> things since it's been driven by people interested in testing and CI,
> but it feels like there's a lot of overlap with the describing the
> suites part of things. It'd be a lot easier to write and read tags like
> the above if we could define some more compact names than git URLs for
> suites/tests.
I see the overlap too. The catalog discussion envisions a mapping of which tests
should be executed for this folder/file or function. This approach is being used,
for example, in the Mesa project for its CI testing. When a new PR comes in,
the system will trigger tests based on the files being modified.
Our discussions on the catalog side are quite basic right now and happening
through the .kernelci.yml file[1]. I believe there is a possible future, built
in a step by step manner, to indentify for given patchset:
* configs to test
* arch/hw to run tests on
* tests must be executed
* expectation of pass/fail for each test
KernelCI wants to work with maintainers to figure out how to make progress
on that.
[1] https://www.youtube.com/watch?v=-LtK1fScFww
Best,
- Gus
parent reply other threads:[~2025-07-31 14:30 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <aIVMPbZcmAvG9z2o@finisterre.sirena.org.uk>]
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=19860e47e60.2269bf19518594.1062927936810569203@collabora.com \
--to=gustavo.padovan@collabora.com \
--cc=broonie@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dzickus@redhat.com \
--cc=kernelci@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=workflows@vger.kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).