Re: [kernelci-members] Working with the KernelCI project

Dmitry Vyukov
2020-09-30T07:07:23Z

On Tue, Sep 29, 2020 at 7:13 PM Nikolai Kondrashov
<Nikolai.Kondrashov@redhat.com> wrote:
>
> Hi Dmitry,
> On 9/29/20 10:52 AM, Dmitry Vyukov wrote:
> > I managed to upload some data manually! Woohoo!
> > https://staging.kernelci.org:3000/d/home/home?orgId=1&refresh=30m&var-origin=syzbot&var-git_repository_url=All&var-dataset=playground_kernelci04
>
> Aweeesooomeee :)
>
> > Some questions regarding data conversion:
> >
> > 1. We usually first get just a crash on 1 instance. Then later we may
> > get a reproducer, or we see it happen on more trees, or we've got
> > bisection results, or something tested a proposed fix. How can we
> > "add" more to the same instance of the bug?
>
> Currently we don't have support for issues/incidents, so we can only accept
> test results without the issue context. That will have to do for the start.
>
> Once we have support for issues/incidents I think we would be able to use the
> feature I'm working on next - an ability to add previously-missing fields to
> an already-submitted object.
>
> So, you would send a test result object, then an issue object with minimal
> information, and then an incident object linking the two. As you get to know
> more about the issue, you can send it again, omitting the fields you already
> sent (or sending them with exact same values), but adding the
> previously-missing fields with the new data. I.e. you first send the issue
> without the proposed fix, and then send it again with the fix.
>
> This feature is still in the research stage, but I'll be working on it after
> the next kcidb release, which is coming in one or two weeks.
>
> Regarding bisection results I was hoping we could represent that data
> implicitly. I.e. by having information about which 'revision' comes after
> which, and executing a query to find a pair of adjacent revisions one of which
> has the bug and another doesn't. In theory that should be possible, but in
> practice... well, you know :) If that fails, we can attach that data
> explicitly somewhere. Or we can simply start with that to have it faster.

Humm... interesting. I guess it can work. We could mark the issue as
happening on the cause commit and as not happening on the previous
commit.
However, one problem is that we don't keep info about the previous
commit as of now, we only store the root cause commit in the database.
Another is that in git it's possible to have several preceding
commits.