Re: #KCIDB: Publishing known issues

["Nikolai Kondrashov" <spbnick@gmail.com>]

On 7/1/22 17:11, Dmitry Vyukov wrote:
>   wOn Fri, 1 Jul 2022 at 14:41, Nikolai Kondrashov <spbnick@gmail.com> 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.

Hope that helps.
Nick