Plan to transition to KDE Frameworks

[Michael Jansen]

> It might make sense to unfreeze master.
> 
> $ git log --pretty=oneline master..
> 4f0d3e Remove KGlobal::locale warning for pure Qt applications
> 88836f add missing file
> 63b8ad Implement locking on non-NFS systems using O_EXCL
> ea17ab accept HTTP headers that are not followed by whitespace after the
> 
> We don't know when a release will be released from the frameworks branch.
> These commits look like they shouldn't wait that long though. They should
> maybe be in 4.7 instead?
> 
> I think maybe people didn't get the memo that there isn't going to be a KDE
> 4.8?

Do you really think it is a good idea to refactor kdelibs and when finished 
try to merge from master/4.7 all at once. You will be in for some nasty 
surprises if you do.

In a company I (the config manager) would merge regulary from those branches 
into the feature branch (in the correct order naturally ( 4.7 -> master -> 
framework) but this is no company and there is no config manager.

Given such a major refactoring branch i would most likely proprose daily 
merges (i work with teams of about 30-50 developers sometimes so that are many 
commits) to keep the pain of conflicts down.

I understand your intentions and desire for a clean history but this is the 
best workflow for this branch. We have to continue our practice to more or 
less commit  / cherry-pick into all branches at once.

You will sit for weeks in the nastiest states if you plan to merge only once 
or seldom. And rebasing is no alternative either because of the coordination 
effort involved. At least my opinion.

Mike

-- 
Michael Jansen
http://michael-jansen.biz