[OpenWrt-Devel] [RFC] commit message in YAML format for new devices

[Adrian Schmutzler]

Hi,

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On
> Behalf Of Petr Štetiar
> Sent: Montag, 13. Januar 2020 10:24
> To: Paul Spooren <mail at aparcar.org>; John Crispin <john at phrozen.org>
> Cc: Martin Blumenstingl <martin.blumenstingl at googlemail.com>; 'OpenWrt
> Development List' <openwrt-devel at lists.openwrt.org>
> Subject: Re: [OpenWrt-Devel] [RFC] commit message in YAML format for new
> devices
> 
> Paul Spooren <mail at aparcar.org> [2020-01-12 11:47:29]:
> 
> Hi,
> 
> > Every commit message for newly added devices must contain a number of
> > hardware information and steps for an initial installation.
> > The hardware information should contain at least the following information,
> > maybe more:
> 
> YAML is really PITA, so you don't want to do this in commit description.

There are also cases where we use information about devices which is subject to change, e.g. unsupported features. If we rely on the commit message, those will stick to their original state/values, no matter whether support has been patched in later.

I'd much prefer to have a dedicated file, which then could be updated as needed. I never understood why the old discussion on this stopped.
ynezz' concept discussed below looks promising to me, I would support this approach if someone actually wanted to make the effort.

Best

Adrian

> 
> It should be external file YAML file, with defined schema, so you can validate
> its correctness.
> 
> See my previous info http://lists.infradead.org/pipermail/openwrt-devel/2019-
> May/017082.html
> 
> > If you have a tool to extract such data or ideas on how to create such,
> > that'd be great.
> 
> See the kernel tooling link above.
> 
> > As an alternative I could also create a shell script that extracts data on a
> > running machine, but that might miss some details.
> 
> Or ideally merge the information from both sources (DTS and runtime).
> 
> John Crispin <john at phrozen.org> [2020-01-13 09:47:54]:
> 
> > I think this will turn into aproblem where functionally sane patches will
> > turn into hassle to get merged. we could encourage folks to send the yaml
> > file as a companion email I guess.
> 
> If there's good tooling(schema, validation etc.) and documentation around, it
> should be as easy as:
> 
>  - make device-yaml-prepare IP=10.0.0.1 DTS=target/linux/foo/dts/device.dts
>    [*] generating device YAML from DTS...
>    [*] adding runtime details from device at 10.0.0.1
>    [*] target/linux/foo/info/device.yaml created
> 
>  - $EDITOR target/linux/foo/info/device.yaml
> 
>    (add details which can't be gathered during runtime, factory flashing
>     instructions, UART pinout etc.)
> 
>  - make device-yaml-validate target/linux/foo/info/device.yaml
>    OK!
> 
>  - make device-yaml-preview target/linux/foo/info/device.yaml
>    [*] check http://127.0.0.1:8000
>    (or launch browser directly via xdg-open or such)
> 
> We could simply start with opt-in (bonus points if you include such YAML file
> along with the support for a new device) and once the dust settles we could
> start talking about it as somehow more or less mandatory requirement.
> 
> -- ynezz
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200113/3c20bba5/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel