Why bother with PRs for usermods

[blazoncek]

Since usermods were converted to libraries (and can be included from any repository using lib_deps) is there any reason to keep PRs for usermods? Do you intend to merge and then maintain such usermods? Is there a plan for what to do with usermods that no longer work or compile or were abandoned?

I would suggest to keep just a list of all available repositories with usermods instead of bothering to test and "maintain" usermods included with WLED.

Instead I'd encourage users interested in WLED featuring their usermod to submit a change to lib_deps in platformio_override.ini sample. Rather than a PR wit usermod.

There is, however, a downside to such listing: endorsing an unverified and potentially malicious usermod.

Thoughts?

[DedeHai]

we did touch this topic in one of the meetings and IIRC the next step would be to document and also have some "guideline" of when a UM would still be eligible to be in core code.

[softhack007]

I think we would not do ourselves any favour by saying "why bother about usermods" (which is a very strong and exclusive statement).

A badly written UM can still cause lots of troubles, like using the "wrong" setPixelColor() at the wrong time, blocking the main loop for too long, not getting activated when many LEDs are being driven, causing inconsistent global state, etc. We have seen all these problems when reviewing UMs (new or updated) in the past.

Looking at our tickets, currently I see ~34 open issues tagged "usermod". IMHO users will continue to report usermod problems to us, no matter if out-of-tree or not. Plus, what will happen when the author of an out-of-tree mod has no time any more to maintain his work? What happens when a usermod becomes incompatible with the core code, and we have no way to do one-liner fixes easily?

In summary, I think we would not do our users any favour with "why bother", and maybe we would not even do ourselves (maintainers) any favour.

I actually see out-of-tree UMs more as a chance for people to add their own enhancements without needing to be integrated into the core sources. Or for centralizing maintenance of AR (or maybe Animartrix) as a separate repo that can be linked into main WLED, WLED-MM and Moonlight without creating three separate UMs.

Edit: out-of-tree UMs are also an important step for us to learn what it means to "modularize" the codebase (discussed in the last dev ConfCall). Maybe its just too early atm for saying "UMs are not in my department any more".

[DedeHai]

There are usermods that are just not acceptable - like the google calender one or that public transport display - and those should be out of tree. If (or rather when) they brake that is up to the user to fix or run a version of WLED that works with it which will limit the amount of people that can actually compile them.
There is a second option: bring in the usermods to main code but still put them under "duty" of whoever submitted it. If it breaks and no one is able to fix it, it is removed.

[blazoncek]

users will continue to report usermod problems

Only for the bundled ones. Not the ones available.
And even if they do, you can always close such issue directing a user to the usermod creator (takes only seconds compared to minutes or hours to properly review a usermod).

[blazoncek]

under "duty" of whoever submitted it

And if they abandon it? What then?

I am trying to "open the eyes" of WLED team to shove off unnecessary burden of checking and maintaining code that will eventually be used by a handful of people at most.

[softhack007]

I agree with the good points that both of you bring up.

Some usermods are just good for very few people, some are a one-shot adventure of somebody, or even a ball of mud from code quality point of view. In the past we would simply not add them to our usermods collection. Out-of-tree provides a new option for these cases.

[softhack007]

There is, however, a downside to such listing: endorsing an unverified and potentially malicious usermod.

That's another interesting aspect. Indeed if we start a "curated UM list" we might need to give UMs an initial "rating" that's based on a code review done by the team. Maybe we can learn from the HA "Quality Rating" for extensions (not sure how HA really calls it).