Dave, Oh, I think during the "release" time we did the opposite. I was basing the logic on the sensible origin of the work on the code: the issue found on stable/1707, so I first verify the fix with the finder in their lab, thus ensuring they test just that change, and then commit and then cherry pick into the master, thus ensuring the commit message on the master gets the reference to the other commit.
Of course, any new things and the minor bug fixes, especially those I would find myself or someone else on master, would go to master first. At least that was my logic - but I am happy to replace it with better one! :-) --a > On 25 Aug 2017, at 14:32, Dave Wallace <dwallac...@gmail.com> wrote: > > Andrew, > > IMHO, best practice is to always commit to master first, then cherry pick to > stable branches as required. That being said, I'm not sure if this has been > explicitly agreed upon by the VPP community. > > Thanks, > -daw- > >> On 8/25/17 3:38 AM, Andrew Yourtchenko wrote: >> Dave, >> >> Yeah, those things are found throughout testing of stable/1707 with various >> control planes (openstack etc), so I first deal with them in stable/1707 and >> after the commit id is there, cherry pick into master (so i made >> https://gerrit.fd.io/r/#/c/8207/ for master now). Those are few things that >> need to go in before we can stamp a 17.07.1... >> >> --a >> >> On 24 Aug 2017, at 23:54, Dave Wallace <dwallac...@gmail.com> wrote: >> >>> Andrew, >>> >>> I just merged https://gerrit.fd.io/r/8156 into stable/1707 and afterwards >>> realized that it has not been committed to master. Shouldn't this be >>> included in master as well? >>> >>> Same thing with https://gerrit.fd.io/r/#/c/8147/ -- is there a reason this >>> is not being committed to master, then cherry-picked to stable/1707? >>> >>> Thanks, >>> -daw- >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
