KDE/4.11 branched what to do with kde-workspace?

[David Faure]

On Thursday 11 July 2013 11:55:54 Sebastian Kügler wrote:
> I'd be in favor of moving master to Qt5/Frameworks5 soonish:
> 
> - I don't want to have to keep track of merging between 3 branches, 2 is 
>   really enough
> - kde-workspace developers have decided to move onto Frameworks5 after 4.11
> is  out, using master for this is natural
>
> This means that, just like with kdelibs, you should use the KDE/4.11 branch 
> if  you want to build "the current version" from git.

This knowledge is outdated, we changed that in kdelibs to go back to something 
that created less surprises.

I feel strongly about what kde-workspace should do in the current situation, 
actually, after having gone through multiple solutions with kdelibs:

*Minimize disruption*

This means:

* develop qt5/frameworks stuff in a frameworks branch

* let master be the branch that will become 4.12, even if you (= the workspace 
developers) don't intend to do more than bugfixing on 4.x, there will always 
be a need to separate "fixes that can go into the next bugfix release" and 
"fixes that need a new i18n", or smallish features contributed externally.

* merging from 4.11 to master is really not a problem. In fact if you don't
do anything else in master, it will really be trivial. In comparison, the 
merge from master to frameworks is always going to be infinitely more "fun", 
given all the changes you're going to do to the destination branch.

Really: "master" is not "where most developers work". master is: the latest 
version, but still usable. That's what everyone building KDE from sources 
expects, including all current scripts (kdesrc-build, build-tool, jenkins, 
custom tools, people's heads, etc. etc.). Don't create disruption for hundreds 
of people just to save typing a 10-seconds "git merge KDE/4.11" every 2 weeks 
or so in master.

Minimizing surprises also means doing exactly what kdelibs is now doing 
(forget about the initial plan, it failed). And that means: a stable branch, a 
master branch which is basically the same but gives room to new i18n and 
stuff, and a frameworks branch where most of the development happens.

No changes to anyone's workflow, including translators, testers, powerusers, 
distros, kde-wide bugfixers, etc. The only ones who have to switch to another 
branch is the people switching to a qt5/frameworks based development, and 
these people have a lot more setup to do anyway, the "git checkout frameworks"
is 1% of it all.

Please, pretty please, minimize disruption.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5