On 08/28/2017 12:05 PM, Andrew Yourtchenko wrote:
Dave,
On 28 Aug 2017, at 17:32, Dave Wallace <dwallac...@gmail.com
<mailto: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 :-)
Good point. I agree!
Thanks,
-daw-
--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
<mailto: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
<mailto: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
