> 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
