On Fri, Jun 23, 2017 at 7:06 PM, Shyam <srang...@redhat.com> wrote: > On 06/23/2017 07:00 AM, Pranith Kumar Karampuri wrote: > >> Note that all of this is just my opinion, and based on working with >> many >> different projects that use git (or other tools) to identify patches >> that could be candidates for backporting. In general, the more details >> that are captured in the commit message, the easier it is to get an >> understanding of the different patches in different branches. >> >> >> Yes, I am also for as much information as possible in the commit with >> least amount of human effort. In time I would like us to get to a point, >> where we just have to say: backport release-3.12 release-3.11 >> release-3.10 and the script should clone, send the patches on gerrit and >> do recheck centos, recheck netbsd, so the only human effort has to be to >> be merge the patch >> >> > My opinion is that we should retain the information that we currently > provide, for 2 reasons, > > 1) Change-Id is gerrit specific, so if we move away at some later point in > time, this is not going to help (yes we can search the git log for the same > change ID etc. but as discussed in this thread, it is not git standard, it > is gerrit addition) >
If we move away from gerrit the information we provide now about what is the patch on master etc are also not of any help. > > 2) Using the same Change-Id is not enforced, so till we do that, getting > to this point is not feasible. > This is a valid point I think. But we can provide extra checks in smoke to check if it is not a backport with correct change-id. So it has solutions > > Shyam > -- Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel