[Gluster-devel] reagarding backport information while porting patches

[Pranith Kumar Karampuri]

On Fri, Jun 23, 2017 at 7:06 PM, Shyam <srangana at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170623/851ee3ec/attachment.html>