Animesh, cherry-picking from a single branch will cause conflicts in the long run (of two to three months) so it is a major problem with the way we release now. Also it will add the code and I was not convinced that merging was better until Leo showed me a history graph as example. With merging a lot more history is preserved and it is easier to see how the present state of the code came to be. I don't think it is an end goal but it is very convenient for an RM.
On Thu, Aug 7, 2014 at 8:40 AM, Animesh Chaturvedi <animesh.chaturv...@citrix.com> wrote: > >> >> (Like most of the internet...) I strongly believe using cherry picks as the >> basic >> tool for (release) branch management is one of the worst choices you can >> make. >> >> But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1] >> > [Animesh] Leo I don't mind moving to merging branches rather than > cherry-picking for technical reasons, but I am not sure cherry-picking is to > blame entirely. Using it all the time caused the pain. When Chip and I were > running releases we started cherry-picks when we got closer to RC. I did not > see cherry-pick as a big pain for 4.2 and 4.3 where I was the RM. RM cannot > scale if they are spending most of their time in cherry-picking or merging > branches into release branch. It needs to be done when they are reasonably > confident that the churn will be limited otherwise RM will get drowned in all > these requests (be it cherry-pick or merge branch). And also I have used > cherry-pick with -x flag which appends "cherry-picked from ...' to the > original commit message in order to indicate which commit this change was > cherry-picked from. > > > > -- Daan
