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 part 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 users?
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. https://github.com/yast/yast-registration/pull/113) 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 modules 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 READE.md, see https://github.com/yast/yast-registration 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@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org