Two branches for KMix?

[Christian Esken]

Am 01.07.2015 um 22:27 schrieb Alexander Potashev:
> 2015-05-21 14:56 GMT+03:00 Alexander Potashev <aspotashev at gmail.com>:
>> Hi everyone,
>>
>> I don't understand why doesn't KMix use the common approach with two
>> branches - "master" and "frameworks"? There is instead a CMake switch
>> to build the KF5 version.
>>
>> IMO, this is harder to maintain and I suggest that a "frameworks" is
>> created and both branches be free of "#ifdef X_KMIX_KF5_BUILD"
>> constructs.
>>
>>
>> Why do I bother? Because I was going to push a little patch regarding
>> localization of KF5 version and it was hard to decide if it should be
>> guarded with ifdef X_KMIX_KF5_BUILD. If we had two branches, I would
>> simply push to "frameworks" and leave "master" alone without need to
>> test the second time against KDELibs4.
>
> Hi,
>
> Looks like nobody actively objects to splitting KMix into two
> branches, so I'll do it now:
> - Branch "master" will contain KDELibs4-based code for now,
> - Branch "frameworks" will contain KF5-based code.

Hello Alexander,

sorry about answering so late. The mail got stuck in a pretty well 
hidden Spam-Folder. Additionally I am not really into KDE development at 
the moment.


First, thanks for stepping forward. Your question definitly deserves an 
answer. The short version of my answer is:
  "Changing the branch is complex on an organizational level, and I have
   no idea (and do want to spend the time) in finding out how to do it."

Now the long version:
---------------------
There are several reasons for the #ifdef X_KMIX_KF5_BUILD:
1) One can "copy" the git version to create a KDE4 release version
2) Features and bugfixes don't require merging / patching
3) It needs a lot of coordination work with the affected parties

Actually, the latter is probably one of the most important aspect. All 
affected parties would need to know about the change and react on it. I 
am speaking of translators (3), build systems (2), code style checker 
(1) and so on. Also important are packagers and distributions, as likely 
nobody will pick up the branch when not explicitly informed.

Alexender, you seem to be accustomated to the "frameworks" approach. Can 
you tackle the tasks above? Otherwise I fear that the branch you have 
created may sit around idle with noone actively using it.

   Christian

Some helpful links:

(1) http://ebn.kde.org/krazy/reports/kde-4.x/kdemultimedia/kmix/index.html
(2) 
https://build.kde.org/view/branchGroup%20stable-qt4/job/kmix%20Applications-15.08%20stable-qt4/
(3) http://l10n.kde.org/

https://techbase.kde.org/

_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia