Hi Kendy, On Tue, 31 May 2011 15:35:07 +0200 Jan Holesovsky <[email protected]> wrote:
> was pushed to both master and libreoffice-3-4, but the code removing > this line just to master. That correctly conflicted - and the person > doing the merge [me in this case - sorry for that] - picked the > version containing that line [either that I overlooked that, did not > investigate enough, or the tooling played tricks on me, and picked > that automatically - I don't remember]. I am not too concerned with a manual merge error. Such thing will happen. I would be concerned if this would fly by "under the radar" by tooling doing too much magic. > The conclusion is that whatever way anybody chooses (committing just > to release branch, or committing to master, and cherry-picking to the > release branch), the person has to be consistent in the choice when > there are subsequent fixes. Well, the second fix was not critical enough for 3.4 (there were reviews in place at that time already). But lets assume me guilty in this case, because I did both fixes -- if the second fix was by somebody different on master, he could hardly have known about this being also on the release branch (and given the activity on master, it is quite possible that such things happen, even if only partially). > [And before you think "this wouldn't have happened if we never merged > the release branch back into master, because we would be always > cherry-picking" - I just have a counter-example of a fix that was > committed to master quite some time ago, but after the libreoffice-3-4 > branch-off, and fell though the cracks - nobody noticed that it hasn't > been cherry-picked to libreoffice-3-4.] How does the merge from release to master help to get something on the release branch? Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
