Hi Bjoern, On 2011-05-31 at 14:30 +0200, Bjoern Michaelsen wrote:
> I just noted that commit > bootstrap:f6ada6a7bf27fd8e0a50f0096604f541beca06e1 > got silently reverted by one of the recent merges. The commit > itself is uncritical, but do we have a general problem here? It does > not seem as if there was any manual intervention at all for this upon > merge. I investigated, and it happened because the code introducing the $(info gb_LinkTarget_add_linktarget_objects,$(1),$(2)) 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]. > Silently dropping changes from master seems to be a serious issue to > me. All would be fine if either everything [the original code as well as the fix] was pushed to both libreoffice-3-4 and master, or everything to just one of these branches. 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. [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.] Regards, Kendy _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice