Plan to transition to KDE Frameworks
kde at michael-jansen.biz
Sun Aug 7 13:46:45 BST 2011
> 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
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.
More information about the kde-core-devel