[Gluster-devel] reagarding backport information while porting patches

[Shyam]

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

>
>
>
>
>
>             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