All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 0/7] docparse improvements
Date: Mon, 01 Nov 2021 12:20:44 +0000	[thread overview]
Message-ID: <87cznkoxyc.fsf@suse.de> (raw)
In-Reply-To: <YX+6iWEzwaTqbYua@yuki>

Hello,

Cyril Hrubis <chrubis@suse.cz> writes:

> Hi!
>> > Still working on a prototype based on tree-sitter would take a week or
>> > two worth of time and I would like to get the metadata fixed now, so
>> > that I can finally move on with runltp-ng. So I would slightly prefer
>> > merging the patches for the current solution first, then we can have a
>> > look on tree-sitter in the next LTP release cycle. What do you think?
>> 
>> I think there is a small risk
>> 
>> 1. It turns out that with tree-sitter it would make more sense to use a
>>    different meta-data format.
>
> What do you have in mind? I do not think that we should dramatically
> chante the json structure we do have now.

Whatever tree-sitter produces most naturally and requires the least
amount of massaging.

>
>> 2. Someone starts building on the current solution without realising it
>>    might change
>>
>> Of course this can be mitigated by saying that the implementation and
>> format are subject to change.
>
> My approach here is to build the runltp-ng as a set of reusable
> libraries, one of them would be a parser for the metadata that would
> provide interfaces for the common queries. That makes the metadata an
> intermediate format that could evolve over time. On the other hand I do
> not expect big changes in the metadata format.
>
>> Note that in general I think it's best (on bigger projects) to have an
>> alternative branch for big changes where one needs to "rush" to an
>> end-to-end solution. Most likely we need an alternate branch for
>> integrating runltp-ng and the executor.
>
> We can even do this in a separate github repository or whatever works,
> but still we have to agree on general direction.
>
> I still think that the best solution here is to apply this patchset and
> put the tree-sitter on TODO. Unlike tree-sitter this is neither big nor
> radical change and it would allow us to proceed with other stuff that
> has been blocked for several releases at least.

As discussed in IRC, I prefer the route of trying either Sparse or
Tree-sitter first to produce the metadata. However please go ahead and
make the decision. After all once we have better automation it will
reduce the burden on reviewers.

-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2021-11-01 12:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-18 15:47 [LTP] [PATCH 0/7] docparse improvements Cyril Hrubis
2021-10-18 15:47 ` [LTP] [PATCH 1/7] docparse: Implement #define and #include Cyril Hrubis
2021-10-29  8:26   ` Petr Vorel
2021-10-29  8:27   ` Petr Vorel
2021-10-18 15:47 ` [LTP] [PATCH 2/7] docparse: Add tests Cyril Hrubis
2021-10-22 11:32   ` Petr Vorel
2021-10-25 12:46     ` Cyril Hrubis
2021-10-25 20:00       ` Petr Vorel
2021-10-22 11:41   ` Petr Vorel
2021-10-25 12:51     ` Cyril Hrubis
2021-10-25 20:01       ` Petr Vorel
2021-10-18 15:47 ` [LTP] [PATCH 3/7] docparse: data_storage: Add integer type node Cyril Hrubis
2021-10-18 15:47 ` [LTP] [PATCH 4/7] docparse: Implement ARRAY_SIZE() Cyril Hrubis
2021-11-01 12:36   ` Richard Palethorpe
2021-11-01 13:18     ` Cyril Hrubis
2021-10-18 15:47 ` [LTP] [PATCH 5/7] docparse: Add type normalization Cyril Hrubis
2021-10-18 15:47 ` [LTP] [PATCH 6/7] docparse: Group data to 'testsuite' and 'defaults' Cyril Hrubis
2021-10-18 15:47 ` [LTP] [PATCH 7/7] docparse/Makefile: Do not abort on missing generators Cyril Hrubis
2021-10-22 11:29   ` Petr Vorel
2021-10-25 12:48     ` Cyril Hrubis
2021-10-27  9:47       ` Petr Vorel
2021-10-18 15:48 ` [LTP] [PATCH 0/7] docparse improvements Cyril Hrubis
2021-10-27 13:22 ` Richard Palethorpe
2021-10-27 13:48   ` Cyril Hrubis
2021-10-28  8:11     ` Richard Palethorpe
2021-10-29  8:54       ` Cyril Hrubis
2021-11-01  9:04         ` Richard Palethorpe
2021-11-01  9:59           ` Cyril Hrubis
2021-11-01 12:20             ` Richard Palethorpe [this message]
2021-11-01 15:10               ` Cyril Hrubis

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=87cznkoxyc.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.