On 06/10/2022 10:21, Johan Hovold wrote: >> What to track: >> 1. Which bindings to convert to YAML, >> 2. Missing compatibles (either entirely or because of missing conversion), >> 3. `dt_binding_check` warnings (usually connected with 1-2), >> 4. `dtbs_check` warnings. >> >> Rob's bot gives us daily output for 1-4, but how can we track current >> efforts to avoid duplication of work? Also it would allow people to find >> tasks for them to get contributions to Linux kernel :). Is anyone in >> community interested in tracking it together, in a public way? > > Is this a real problem that needs fixing? I mean how often does it > happen that people submit the same YAML conversion for example? Since it > doesn't take that long to do a conversion, I'm not sure what tracking > this on some webpage buys us. It's better to just search lore before > starting a new conversion. Or search the linux-next tree to see what's > still pending. In terms of DT bindings conversion to DT schema: If I were not checking for ongoing work, I would duplicate effort like ~10 times. Few other folks hit it few times, at least. Several bindings are being converted for ~1 year! In terms of DTS warnings - it's difficult even to check/search. For what do you search? Warnings? Pretty often they are not part of commit msg. By file? Then you might have many, many unrelated search results. > > Similarly for the other points above, as it doesn't take very long to > add a missing compatible or fix a warning it seems a bit excessive to > try to track this manually. True, some are trivial. Some however need fixing the binding which takes time. > Perhaps a list of pending conversions or missing compatibles could be > useful for someone who's short on work, but it's bound to get outdated > pretty quickly. Another point is to have the visibility on the amount of work to be done. But I understand that's maybe topic just for few, e.g. me, so I can just track stuff for myself. > >> If so, where? >> A. elinux.org (needs some formatting when pasting the output from tools) >> B. gitlab pages/wiki (maybe scripts could parse tools and create the page?) >> C. gitlab dedicated repo - some text file >> D. Linux kernel TODO file (might be difficult to keep updated) >> E. kernel.org wiki (requires LF accounts, AFAIK, a bit pain to edit; I >> have it for Exynos but I don't find it usable - >> https://exynos.wiki.kernel.org/todo_tasks) >> >> I am leaning towards Gitlab pages because they could be quite automated >> - with CI or with scripts. >> >> The point would be to list all of tasks (1-4 from the first list), keep >> it updated with new results, pick/assign tasks and mark as done. > > I don't really see the need for more process here, sorry. > > If I'm working on support for a new platform and the DT checker warnings > gets too noisy I may pick some of the low hanging fruit. In the odd > chance that someone beats me to it, it's not the end of the world. Thanks for the input! Best regards, Krzysztof
