On Tue, Apr 16, 2013 at 10:02:29AM +0200, Michal Filka wrote:
I assume that we will need to maintain ycp and ruby code for some time together (SLE SP3, SP4). So, I'd like to know if it is possible to use ycp killer for converting patches.
I agree, that it makes hard to convert patches. But on other side, for me more important is to properly make such patch. So in ruby you can very intensive test such change and behavior and then do such change in ycp should be relative easy. Or other way when you have patch for ycp, then you should write test for problematic part that demonstrate problem in ruby and then just implement it.
Doing a work twice is always problem ;-) I see two ways: - translate whole module again after each patch in ycp. Problem is potential loss of changes done in ruby code only. - translate the patch only (if possible) and try to integrate it somehow by hand.
I think that after the conversion, the code bases will diverge, because it will be finally possible to make cleanups in the ruby code. Fixes from SLE 11 will have to be ported manually. Yes, it will be extra work, but since SLE 12 will have been out, the demand for SLE 11 patches will decrease (not overnight, but eventually). I don't see how we can make this cost smaller but I hope that the benefits are far greater.
Another note is loss of history in github.
It is just partially true. You don't lost history, it just add one more step, when you need to check old ycp code that match ruby code and see history in ycp.
This becames to be a problem in case of refactoring in ruby code.
Unlike the previous problem, we can simulate this one in advance easily and try some ways to make it easier for us. Like David said, certainly it will help to store the original YCP path. -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu