Mailinglist Archive: yast-devel (54 mails)

< Previous Next >
Re: [yast-devel] Yast Development after SLE 12
Dne 12.6.2014 16:30, Lukas Ocilka napsal(a):
What we will need is the "Refactoring and Cleanup" (RAC) phase, to be a regular
of the development.

Great! That step was always missing in the Yast development.

- Which parts deserve the refactoring (e.g., those that we often touch,
those, that are not understandable anymore, buggy, ...)? Which are
your most-favorite ones?

It's hard to say, there are many bad modules... But I think we should start
in yast2 (the main library), the code there is shared so it should look nice, should be well tested and documented.

- How deep should the refactoring be, we have to keep the current
"API", but what should be considered the API as we might be the only

When we decide to refactor from the converted RYCP code to clean Ruby
we will need to change the API anyway (use objects, follow traditional Ruby naming conventions, etc...). And if we want to reuse the Yast code even more we will need to move away from the old Yast architecture and build clean libraries (available as gems).

So I would not be bothered about the API changes, the refactoring will very likely break the existing code anyway if we want to have nice Ruby (!) API.

- As we will have to add testcases for everything we refactor, should
we also move code from "clients" and "includes" to libraries to be
easier to test?

Yes, that's a good idea to get rid of (RYCP) includes and clients.
It's hard to test it and it's a relict of the Yast architecture which
not known for regular Ruby developers.

- How and where to run CI tests for all supported branches?

Jenkins can be easily enhanced, after switching to "osc" backend we can
easily add another Git branches and OBS build targets.

I'd like also to use Travis in addition to Jenkins. I currently use it in the registration module. The main advantage is that it runs the tests _before_ a pull request (branch) is merged.

Another advantage is that the code coverage tools can be easily integrated (see "coveralls") so you can also see the code coverage change _before_ merging a PR. And the status is updated on the fly, even after adding new commits to the PR (see e.g.

So you can easily check whether the code coverage is still OK and you can ask the PR author to add more tests when the code coverage decreases too much.
(Or you can specify the minimal code coverage, if it less then the tests fails.)

You can actually run almost anything you want at Travis, e.g. suse-connect
runs "rubocop" tool which checks the coding style. The build fails if you do not follow the predefined coding standard.

However, testing yast code is limited at Travis, the problem is that there is no
Yast available so you can only test the code which does not use other Yast
or you need to mock heavily...

I'd like to improve this at the next workshop/hackweek.

- How to measure the success? I'd love to see automatically generated
metrics and code coverage. Metrics could help us to identify the
most-rotten pieces.

I have added the code coverage and metrics badges to the registration
main, see

So you can have a quick overview just looking at Github.

- Where and how to run automatic integration tests? Will openQA help?
We could build our own installation image the same way we did it for
the New Installer, testing this image automatically is just another
logical step.

Building an own image is cumbersome and requires quite a lot of maintenance
(you list the packages included in the ISO and if a package is renamed or there is new dependency then you need to update it). Maybe there is some Build Service magic for this, but from my experience it's too much work.

For NI it was the only way, but I'd prefer using e.g. standard Factory images instead of building our own image whenever possible.

- Additional step is to run such tests for all supported products since
we have enabled users to install updates during installation - this
is connected to refactoring only partly, it's essential even if we
haven't refactored a single line of code

Um, I think this is somthing rather for QA automation, it tests whole distribution, not Yast only...


Best Regards

Ladislav Slez√°k
Yast Developer
SUSE LINUX, s.r.o. e-mail: lslezak@xxxxxxx
Lihovarsk√° 1060/12 tel: +420 284 028 960
190 00 Prague 9 fax: +420 284 028 951
Czech Republic
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >