Hi, The current Yast code that we will have in SLE 12 is partly automagically translated from YCP to kind of Ruby (also called RYCP), is still using many YCP-like methods for backward compatibility. Partly - because we have already cleaned up some pieces when touching them, following the Boy-Scout Rule [#1] and so the feel quite OK. Of course, we will not be able to cleanup everything we wanted and when SLE 12 is out, we will have to maintain the codebase for years. What we will need is the "Refactoring and Cleanup" (RAC) phase, to be a regular part of the development. Obviously, result of the RAC has to end up in SLE 12 codebase. I've already started talking with the Product Management (PM) and they are more-or-less aligned with this idea. And of course, I'd love to see the RAC in openSUSE as well. For that reason, it might make sense to develop both in the same branch as long as possible (SLE 12 GA maintenance [+ SP1 development?], openSUSE development). I'd like to improve these interconnected areas: - fewer bugs - better test coverage - better code maintainability in the future There are many open questions that need to be brainstormed before we decide and start planning, to name some: - 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? - 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? - 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? - How and where to run CI tests for all supported branches? - 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. - 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. - 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 A few buzzwords for the fun :) - automation (don't do manually what you don't need to do) - unification (DRYing) - standardization (use libraries, don't write it yourself) #1 http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule #2 http://martinfowler.com/articles/workflowsOfRefactoring/ Thanks for your time and I'm looking forward your ideas and opinions Bye Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org