[Gluster-devel] reagarding backport information while porting patches

[Shyam]

On 06/23/2017 10:19 AM, Shyam wrote:
> On 06/23/2017 10:11 AM, Pranith Kumar Karampuri wrote:
>>
>>
>> On Fri, Jun 23, 2017 at 7:24 PM, Shyam <srangana at redhat.com
>> <mailto: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>
>>         <mailto: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.
>
> If we write a script that you alluded to (and in a previous post Jeff
> Darcy alluded to [1] when we were discussing parts of Change-Id
> enforcement etc.), then we are better off... instead of changing
> documentation and requesting people to follow new practices.
>
> [1] Jeff's mail on the same lines

The mail thread: 
http://lists.gluster.org/pipermail/gluster-devel/2017-March/052220.html

>
>>
>>
>>
>>
>>
>>             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/show_bug.cgi?id=1428047
>>     <https://bugzilla.redhat.com/show_bug.cgi?id=1428047>
>>
>>
>>
>>
>>             Shyam
>>
>>
>>
>>
>>         --
>>         Pranith
>>
>>
>>
>>
>> --
>> Pranith