Plan to transition to KDE Frameworks
steveire at gmail.com
Sun Aug 7 18:06:52 BST 2011
Good point well made.
I think what you propose makes a lot of sense.
On 8/7/11, Michael Jansen <kde at michael-jansen.biz> wrote:
>> 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
> 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
> 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.
> Michael Jansen
More information about the kde-core-devel