bring yast module development closer to basesystem developers

[mvidner]

(PT, @ptesarik) you should really try to bring yast module development closer to basesystem developers
(PT) bonus points: if my PR gets merged, then yast will only lag a few days behind bleeding edge in terms of features
(@mvidner) PT: hmm! so, what would help you (or another base-dev) to develop/fix yast modules? let's write down the barriers
(PT) apart from learning some ruby basics (which cannot be avoided), a clear explanation what is legacy stuff that should be avoided in new code
(PT) all these Convert.to_string and Ops.set are confusing as hell until you realize they're not merely unnecessary, but harmful
(PT) next thing, a more user-friendly way to design and/or test the UI elements would be great
(PT) I know you guys don't have time to write a complete IDE (anyone here remembers Delphi?), but using hashmaps with magic keys is ... just too much
(PT) for those who don't know Delphi, have a look at Qt Creator to get an idea

[ptesarik]

Additionally, I would appreciate an introduction to the underlying YaST concepts (e.g. what are normal, autoinstall, autoupgrade modes). What is the expected outcome if something was already configured on the target system?

Next, there is a lot of documentation, but it is not linked from the README.md of every module repository. Some are empty (https://github.com/yast/yast-kdump/blob/master/README.md), some do not provide any information on development (https://github.com/yast/yast-docker/blob/master/README.md), some contain duplicate information (https://github.com/yast/yast-network/blob/master/README.md), which must be a nightmare to keep up to date in all places…

Even when you find something, it links to:

• YaST documentation page, which happens to give a beautiful 500 Internal Error
• SCR#RegisterAgent, which at least produces a nicely formatted 404 Oops, We Couldn't Find That Page
• Yast.path, which does the same

The home page is in a much better shape, so what about replacing all the READMEs with a link to that one? Or maybe to the Contributing page, since those files are more likely to be found by developers.

[ptesarik]

There should be a small chapter about YaST Legacy at https://yastgithubio.readthedocs.io/en/latest/. It doesn't have to go into much detail, simply list a legacy construct and the suggested equivalent for new code. For example, searching for Builtins on the development pages finds only this one mention:

• https://yastgithubio.readthedocs.io/en/latest/code-review/#nice-to-have-nth

The Legacy page should be linked from here, so newbies understand what to use instead of Ops and Builtins.

Still, people will try to mimic whatever code is already all around the place they're patching, because that's usually more fun than reading the documentation first. Not sure what can be done about it, if anything.

[ptesarik]

Why is WSL almost the first thing you get to read if you actually decide to read the devel docs? Why is it so important to developers?

[ptesarik]

Likewise, Package Submission is probably done frequently by members of the YaST core team but not by a casual contributor. As such, it had better be moved further down the document.

[mvidner]

Why is WSL almost the first thing you get to read if you actually decide to read the devel docs? Why is it so important to developers?

It's because the topics are sorted by their filename (which is different from the actual topic heading), and W comes before a in ASCII...

[mvidner]

Remaining:

• Make rubydoc.info more reliable or migrate somewhere else
• Write a YaST Legacy topic, where legacy means the YCP days, hurry before d-installer makes Ruby the legacy 🤣