Good point well made. I think what you propose makes a lot of sense.
On 8/7/11, Michael Jansen <k...@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 >> 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 >
