From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: Date: Sat, 2 Jul 2022 17:02:53 +0300 MIME-Version: 1.0 Subject: Re: #KCIDB: Publishing known issues References: <54539125-b4fe-c219-cad9-e511e6271875@gmail.com> <2d739264-6ece-1c8a-30a0-c1d96a8a8e62@gmail.com> From: "Nikolai Kondrashov" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-ID: To: Dmitry Vyukov Cc: kernelci@groups.io, syzkaller , =?UTF-8?Q?I=c3=b1aki_Malerba?= , Vishal Bhoj , Alice Ferrazzi , automated-testing@lists.yoctoproject.org, Cristian Marussi , Tim Bird , Johnson George , Veronika Kabatova , Guillaume Tucker On 7/2/22 10:59, Dmitry Vyukov wrote: > On Fri, 1 Jul 2022 at 17:05, Nikolai Kondrashov wrote: >> >> On 7/1/22 17:11, Dmitry Vyukov wrote: >>> wOn Fri, 1 Jul 2022 at 14:41, Nikolai Kondrashov wrote: >>>> There's obviously lots and lots more to think about and discuss regarding >>>> "known issues", but please tell me what you think about this particular >>>> aspect. Everything else is welcome too, of course :) >>> >>> Maybe I am missing something, but have you considered making the KCIDB >>> server assign these versions to take this burden from all clients? >>> Users will effectively "modify" entities, except that KCIDB won't >>> actually modify but rather insert new versions. The version can be >>> precise-enough timestamp as you mentioned. >> >> Thank you for your prompt response, and for a good question, Dmitry! >> >> Yes, I considered that for a while, from various angles. Yes, that would be >> simpler for submitters in many cases. >> >> However, it will make the KCIDB protocol more complex (both to understand and >> to implement) by introducing different behavior for different types of objects. >> >> It will force KCIDB to implement comparing issue parameters/contents, instead >> of just comparing version numbers, in order to avoid useless retriage when the >> same issue is submitted multiple times without changes. E.g. when related >> issues are simply submitted together with test results for every revision. >> >> It will also either force KCIDB to introduce global synchronization for >> reliable version number generation, or to use mostly de-synchronized, but >> unreliable timestamp-based versions for *all* submitters, regardless whether >> they can actually do better or not. In this way, this tradeoff is similar to >> having submitters generate their own object IDs. > > On the syzbot side we fully control database schema and code, so > adding bug versions should not be a problem at least for major bug > status changes. Glad to hear that. Thank you, Dmitry! This will help us get to a working implementation faster. Would also love to hear what others maintaining known issues think about this. Nick