Re: reagarding backport information while porting patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)

2) Using the same Change-Id is not enforced, so till we do that, getting to this point is not feasible.

Shyam
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux