Dave, > On 28 Aug 2017, at 17:32, Dave Wallace <dwallac...@gmail.com> wrote: > > Andrew, > > Having got some feedback from others, I don't think there is any one right > way. > > For bugs found in a stable branch, it makes sense to push the original patch > there, then cherry pick to master and then identify if it makes sense to > cherry pick it to any other branches. For bugs found in master (which is > what I originally had in mind), going in the other direction makes more sense.
Aha, cool! We are in sync. > > So I guess the best thing would be to ensure that the branch which the bug > was found is included in the body of the comments section of the patch and > what other branches require the fix -- or maybe this information belongs in > Jira. The most important thing is to ensure master has all of the applicable > patches in it. Absolutely, I always ensure that. The reason I didn't cherry pick from the hip before the commit is cherry pick after the commit includes the commit ID, so I think it is useful to have that in the commit message :-) --a > > Thanks, > -daw- > >> On 08/25/2017 04:57 PM, Andrew Yourtchenko wrote: >> 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
