On Thu, Jun 12, 2014 at 05:02:24PM +0200, Josef Reidinger wrote:
On Thu, 12 Jun 2014 16:30:06 +0200 Lukas Ocilka <lukas.ocilka@suse.com> wrote:
[Ruby YCP - answered in a separate mail]
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 think it make sense as long as opensuse and SLE12 do not much diverge in sense of configured stuff. If e.g. parted changed in opensuse, then it is hard to keep same code ( and similar for other critical parts like grub2, systemd, wicked etc. ).
OK. Does it make sense with schedules too? openSUSE 13.2 still in November 2014? Any public comment about SLE12 SP1?
I'd like to improve these interconnected areas:
- fewer bugs - better test coverage - better code maintainability in the future
Do we focus on everything? What are our goals for the refactoring? How do we measure success? Developer happiness matters to me, but it is hard to quantify. I really enjoyed the progress spreadsheet we had for YCP Killer, and I think it is important to find a meaningful metric and see it improving as we work together. So the most important questions below are Which parts to refactor and How to measure success.
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?
From what I see in current development it is license handling, slideshow, ui libraries deserve better API that can benefit from ruby. In general the most important is to refactor parts that will be changed ( due to bugs or features ). So for me it make sense to improve parts that we want change, as it speed up developement and decrease number of bugs.
Some options how to decide WHAT to refactor: 1. Measure code quality everywhere (with metric_fu) and pick the worst code. 2. Measure code changes (metric_fu churn), assuming what has changed in the past will need change in the future. 3. Count bugs. Probably hard on a file level but easy on a package level by counting "bnc" in *.changes. That counts fixed bugs, not reported ones. 4. Count feature requests (done and pending). I think that (1) is wrong, as it is perfectly OK to leave bad code alone as long as it works. For (2) and (3) it should be fairly easy to automate the numbers and I could do that. I don't know about (4).
- 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?
Depends on situation. I think some parts need just small refactoring. Some need quite heavy rewrite, as it is horrible mess.
API is definitivelly autoyast XML, also API is what user can do in UI. Otherwise I think it do not matter.
I agree about the AY API. HOW MUCH depends on 2 things I think: 1. The amount of code needing refactoring (see What above) and our team*time resources. 2. Our ability to refactor properly, that is, change code without fear of regressions, that is, having meaningful tests in place for the changed code. (2) means we should put high priority on testing Autoyast. And get more familiar with openqa for the interactive installation tests.
[Testing, Measuring]
EEMAILTOOLONG. To Be Continued! -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu