kernelci.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
To: Guillaume Tucker <guillaume.tucker@collabora.com>,
	kernelci@lists.linux.dev, gregkh@linuxfoundation.org,
	thorsten@leemhuis.info, regressions@lists.linux.dev
Cc: kernel@collabora.com, linux-kernel@vger.kernel.org,
	Gustavo Padovan <gustavo.padovan@collabora.com>,
	Shreeya Patel <shreeya.patel@collabora.com>
Subject: Re: Kernel regression tracking/reporting initiatives and KCIDB
Date: Mon, 21 Aug 2023 12:30:08 +0200	[thread overview]
Message-ID: <87jztohemn.fsf@collabora.com> (raw)
In-Reply-To: <517c702f-5b75-b999-2224-bc27951f03f3@collabora.com>

On vie, ago 18 2023 at 22:11:52, Guillaume Tucker <guillaume.tucker@collabora.com> wrote:
> KernelCI is not any CI, it's designed to be the main system for
> the upstream kernel.  So it already took the high-level approach
> to look at all this after becoming an LF project and we came up
> with KCIDB and now the new API as the community still needs
> an "active" system and not just a database for collecting data
> from other systems.

That sounds good and I think that's the way to go, but does that mean
that, in theory, most or all current CI systems (0-day, CKI, etc) will
"push" their results to the new KernelCI in the future?

> Right, except you might hit another deprecation hurdle if we
> start changing how things are designed around KCIDB and the new
> API.  There's no doubt KCIDB will be supported for a long time,
> but taking into considerations all the new developments can save
> you a lot of trouble.

So, if using KCIDB as a data source is not a good idea right now, do you
have any suggestions on how to keep contributing to the improvement of
regression analysis?

If the new KernelCI API is already working with a large enough
regression database maybe this analysis work can be plugged into the
pipeline and we can start working on that.

> My point here is that KernelCI started tackling this issue of
> reporting kernel bugs several years ago at a very high level and
> we've come up with some carefully engineered solutions for it, so
> it looks like you're walking in our footsteps now.  The new web
> dashboard, new API & Pipeline and KCIDB which pioneered working
> outside the native realm of KernelCI provide some answers to the
> challenges you're currently investigating.  So maybe it is
> actually the best strategy for you to carry on doing things
> independently, but it would seem to me like due diligence for
> each of us to know what others are doing.

I surely must have missed most of those discussions but I couldn't find
any traces of the functionalities I listed either in a design document
or implemented anywhere. We certainly wouldn't have started this stream
of work if we knew this was already a work in progress. If there are
already concrete plans and some kind of design for this, let me know so
we can contribute to it.

If the solutions that have been engineered so far are still unplanned,
then I agree it'll be better to keep improving on this
independently. But in order to do that we'd need to be able to use other
data sources (KCIDB). Then, once the new KernelCI is ready to implement
these functionalities we can try to move them there after they've been
tested independently.

Cheers,
Ricardo

      reply	other threads:[~2023-08-21 10:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-01 11:47 Kernel regression tracking/reporting initiatives and KCIDB Ricardo Cañuelo
2023-08-02  8:07 ` Thorsten Leemhuis
2023-08-07  8:29   ` Nikolai Kondrashov
2023-08-04 16:06 ` Nikolai Kondrashov
2023-08-08  9:55   ` Ricardo Cañuelo
2023-08-17 13:32 ` Guillaume Tucker
2023-08-18  7:50   ` Ricardo Cañuelo
2023-08-18 20:11     ` Guillaume Tucker
2023-08-21 10:30       ` Ricardo Cañuelo [this message]

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=87jztohemn.fsf@collabora.com \
    --to=ricardo.canuelo@collabora.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guillaume.tucker@collabora.com \
    --cc=gustavo.padovan@collabora.com \
    --cc=kernel@collabora.com \
    --cc=kernelci@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=shreeya.patel@collabora.com \
    --cc=thorsten@leemhuis.info \
    /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).