[Gluster-devel] reagarding backport information while porting patches

[Pranith Kumar Karampuri]

On Fri, Jun 23, 2017 at 7:24 PM, Shyam <srangana at redhat.com> wrote:

> On 06/23/2017 09:48 AM, Pranith Kumar Karampuri wrote:
>
>>
>>
>> On Fri, Jun 23, 2017 at 7:06 PM, Shyam <srangana at redhat.com
>> <mailto: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.
>>
>
> Yes, but it is better to have this information at present than to drop it
> and loose the practice of providing the information.


If we ensure that the link between different branches is taken care of.
Answer to "Is it better to have this practice of providing information" is
subjective.


> Changing habits are hard, I would rather not change the habit at the
> moment.


I agree. It goes both ways, we will not force a habit on new contributors
who are coming to the community this way. IMHO we can make it easier for
someone to contribute to gluster by reducing manual steps. This is one such
step if we can execute it right handling corner cases.


>
>>
>>
>>     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
>>
>
> Yes, this is pending to be done, https://bugzilla.redhat.com/sh
> ow_bug.cgi?id=1428047
>
>
>>
>>
>>     Shyam
>>
>>
>>
>>
>> --
>> Pranith
>>
>


-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170623/b0ca3813/attachment-0001.html>