Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread 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 > wrote:

On 06/23/2017 09:48 AM, Pranith Kumar Karampuri wrote:



On Fri, Jun 23, 2017 at 7:06 PM, Shyam 
>> 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





Shyam




--
Pranith




--
Pranith

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Shyam 

On 06/23/2017 10:11 AM, Pranith Kumar Karampuri wrote:



On Fri, Jun 23, 2017 at 7:24 PM, Shyam > wrote:

On 06/23/2017 09:48 AM, Pranith Kumar Karampuri wrote:



On Fri, Jun 23, 2017 at 7:06 PM, Shyam 
>> 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





Shyam




--
Pranith




--
Pranith

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Pranith Kumar Karampuri 
On Fri, Jun 23, 2017 at 7:24 PM, Shyam  wrote:

> On 06/23/2017 09:48 AM, Pranith Kumar Karampuri wrote:
>
>>
>>
>> On Fri, Jun 23, 2017 at 7:06 PM, Shyam > > 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
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Shyam 

On 06/23/2017 09:48 AM, Pranith Kumar Karampuri wrote:



On Fri, Jun 23, 2017 at 7:06 PM, Shyam > 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. Changing habits 
are hard, I would rather not change the habit at the moment.






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






Shyam




--
Pranith

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Pranith Kumar Karampuri 
On Fri, Jun 23, 2017 at 7:06 PM, Shyam  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
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Shyam 

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@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Pranith Kumar Karampuri 
On Fri, Jun 23, 2017 at 4:21 PM, Niels de Vos  wrote:

> On Fri, Jun 23, 2017 at 03:53:42PM +0530, Pranith Kumar Karampuri wrote:
> > On Fri, Jun 23, 2017 at 3:01 PM, Niels de Vos  wrote:
> >
> > > On Fri, Jun 23, 2017 at 01:47:57PM +0530, Pranith Kumar Karampuri
> wrote:
> > > > On Fri, Jun 23, 2017 at 1:30 PM, Niels de Vos 
> wrote:
> > > >
> > > > > On Fri, Jun 23, 2017 at 09:15:21AM +0530, Pranith Kumar Karampuri
> > > wrote:
> > > > > > hi,
> > > > > >  Now that we are doing backports with same Change-Id, we can
> > > find the
> > > > > > patches and their backports both online and in the tree without
> any
> > > extra
> > > > > > information in the commit message. So shall we stop adding text
> > > similar
> > > > > to:
> > > > > >
> > > > > > > Reviewed-on: https://review.gluster.org/17414
> > > > > > > Smoke: Gluster Build System 
> > > > > > > Reviewed-by: Pranith Kumar Karampuri 
> > > > > > > Tested-by: Pranith Kumar Karampuri 
> > > > > > > NetBSD-regression: NetBSD Build System <
> > > jenk...@build.gluster.org>
> > > > > > > Reviewed-by: Amar Tumballi 
> > > > > > > CentOS-regression: Gluster Build System <
> > > jenk...@build.gluster.org
> > > > > >
> > > > > > (cherry picked from commit de92c363c95d16966dbcc9d8763fd4
> > > 448dd84d13)
> > > > > >
> > > > > > in the patches?
> > > > > >
> > > > > > Do you see any other value from this information that I might be
> > > missing?
> > > > >
> > > > > I think it is good practise to mention where the backport comes
> from,
> > > > > who developed and reviewed the original. At least the commit-id is
> > > > > important, that way the backport can easily be compared to the
> > > original.
> > > > > git does not know about Change-Ids, but does know commmit-ids :)
> > > > >
> > > >
> > > > Change-ID captures all this information. You can know the patch in
> all
> > > > branches with Change-ID, now that we are following same Change-ID
> across
> > > > branches.
> > >
> > > However a Change-Id is not standard git, it is purely a Gerrit thing. I
> > > can't cherry-pick or 'git show' a Change-Id, but that works fine with a
> > > git-commit.
> > >
> >
> > Where do we mention git commit-id now? If we do the backport using
> gerrit,
> > it adds it as "(cherry picked from commit
> > de92c363c95d16966dbcc9d8763fd4448dd84d13)",
> > otherwise I don't think it gets mentioned, right?
>
> Correct, that is just what "git cherry-pick -x" does too. It is one of
> the main requirements we check for backports. It is not enforced, but
> strongly encouraged to have it. Nothing in the commit message is
> enforced, it is up to the maintainers to make sure everything makes
> sense there.
>
> Part of this is also mentioned on
> http://gluster.readthedocs.io/en/latest/Developer-guide/
> Backport-Guidelines/
>
> > > I also like to give credits to the people that originally wrote and
> > > reviewed the change. It is not required, but it is nice to have.
> > >
> >
> > If you do the backport using standard commands Author and committer are
> > correctly shown in the patch, I think the tool already handles it. As for
> > the reviewer etc. as this information is available on the actual patches,
> > if the person who is checking for it really wants it, can find out.
>
> Depends, if the patch is not exactly the same, the author should be
> changed to whoever did the backport and add a note explaining the
> difference. Even cherry-picks can be different, and sending those as an
> author who did not do the (incorrect?) work is wrong imho.
>
> But yes, if a backport is straight forward, the original Author of the
> change can surely be kept.
>
>
> 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


>
> Niels
>
>
> > > > > We should try to have all the needed details in the git
> repository, and
> > > > > not rely on Gerrit for patch verification/checking. When I'm
> working on
> > > > > a patch and wonder why/when something related was changed, I'll
> use the
> > > > > local history, and do not want to depend on Gerrit.
> > > > >
> > > >
> > > > Change-ID is mentioned in the commit which is there in the git log,
> so we
> > > > can figure out the

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Niels de Vos 
On Fri, Jun 23, 2017 at 03:53:42PM +0530, Pranith Kumar Karampuri wrote:
> On Fri, Jun 23, 2017 at 3:01 PM, Niels de Vos  wrote:
> 
> > On Fri, Jun 23, 2017 at 01:47:57PM +0530, Pranith Kumar Karampuri wrote:
> > > On Fri, Jun 23, 2017 at 1:30 PM, Niels de Vos  wrote:
> > >
> > > > On Fri, Jun 23, 2017 at 09:15:21AM +0530, Pranith Kumar Karampuri
> > wrote:
> > > > > hi,
> > > > >  Now that we are doing backports with same Change-Id, we can
> > find the
> > > > > patches and their backports both online and in the tree without any
> > extra
> > > > > information in the commit message. So shall we stop adding text
> > similar
> > > > to:
> > > > >
> > > > > > Reviewed-on: https://review.gluster.org/17414
> > > > > > Smoke: Gluster Build System 
> > > > > > Reviewed-by: Pranith Kumar Karampuri 
> > > > > > Tested-by: Pranith Kumar Karampuri 
> > > > > > NetBSD-regression: NetBSD Build System <
> > jenk...@build.gluster.org>
> > > > > > Reviewed-by: Amar Tumballi 
> > > > > > CentOS-regression: Gluster Build System <
> > jenk...@build.gluster.org
> > > > >
> > > > > (cherry picked from commit de92c363c95d16966dbcc9d8763fd4
> > 448dd84d13)
> > > > >
> > > > > in the patches?
> > > > >
> > > > > Do you see any other value from this information that I might be
> > missing?
> > > >
> > > > I think it is good practise to mention where the backport comes from,
> > > > who developed and reviewed the original. At least the commit-id is
> > > > important, that way the backport can easily be compared to the
> > original.
> > > > git does not know about Change-Ids, but does know commmit-ids :)
> > > >
> > >
> > > Change-ID captures all this information. You can know the patch in all
> > > branches with Change-ID, now that we are following same Change-ID across
> > > branches.
> >
> > However a Change-Id is not standard git, it is purely a Gerrit thing. I
> > can't cherry-pick or 'git show' a Change-Id, but that works fine with a
> > git-commit.
> >
> 
> Where do we mention git commit-id now? If we do the backport using gerrit,
> it adds it as "(cherry picked from commit
> de92c363c95d16966dbcc9d8763fd4448dd84d13)",
> otherwise I don't think it gets mentioned, right?

Correct, that is just what "git cherry-pick -x" does too. It is one of
the main requirements we check for backports. It is not enforced, but
strongly encouraged to have it. Nothing in the commit message is
enforced, it is up to the maintainers to make sure everything makes
sense there.

Part of this is also mentioned on
http://gluster.readthedocs.io/en/latest/Developer-guide/Backport-Guidelines/

> > I also like to give credits to the people that originally wrote and
> > reviewed the change. It is not required, but it is nice to have.
> >
> 
> If you do the backport using standard commands Author and committer are
> correctly shown in the patch, I think the tool already handles it. As for
> the reviewer etc. as this information is available on the actual patches,
> if the person who is checking for it really wants it, can find out.

Depends, if the patch is not exactly the same, the author should be
changed to whoever did the backport and add a note explaining the
difference. Even cherry-picks can be different, and sending those as an
author who did not do the (incorrect?) work is wrong imho.

But yes, if a backport is straight forward, the original Author of the
change can surely be kept.


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.

Niels


> > > > We should try to have all the needed details in the git repository, and
> > > > not rely on Gerrit for patch verification/checking. When I'm working on
> > > > a patch and wonder why/when something related was changed, I'll use the
> > > > local history, and do not want to depend on Gerrit.
> > > >
> > >
> > > Change-ID is mentioned in the commit which is there in the git log, so we
> > > can figure out the information without needing internet/gerrit. So that
> > > part is not a problem.
> >
> > Yes, of course I can figure it out, but it is additional work. Most
> > tools do not know about Change-Ids, like browsing through the code on
> > GitHub; a commit-id will be linked, a Change-Id not.
> >
> >
> We will discuss this further after my question above about commit-id is
> answered.
> 
> 
> > > All of this information was important to mention earlier because there
> > was
> > > no common thing binding all together. With same Change-ID across branches
> > > for a patch, it seems unnecessary to mention this information in the
> > commit
> > > message.
> >
> >

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Niels de Vos 
On Fri, Jun 23, 2017 at 01:47:57PM +0530, Pranith Kumar Karampuri wrote:
> On Fri, Jun 23, 2017 at 1:30 PM, Niels de Vos  wrote:
> 
> > On Fri, Jun 23, 2017 at 09:15:21AM +0530, Pranith Kumar Karampuri wrote:
> > > hi,
> > >  Now that we are doing backports with same Change-Id, we can find the
> > > patches and their backports both online and in the tree without any extra
> > > information in the commit message. So shall we stop adding text similar
> > to:
> > >
> > > > Reviewed-on: https://review.gluster.org/17414
> > > > Smoke: Gluster Build System 
> > > > Reviewed-by: Pranith Kumar Karampuri 
> > > > Tested-by: Pranith Kumar Karampuri 
> > > > NetBSD-regression: NetBSD Build System 
> > > > Reviewed-by: Amar Tumballi 
> > > > CentOS-regression: Gluster Build System  > >
> > > (cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)
> > >
> > > in the patches?
> > >
> > > Do you see any other value from this information that I might be missing?
> >
> > I think it is good practise to mention where the backport comes from,
> > who developed and reviewed the original. At least the commit-id is
> > important, that way the backport can easily be compared to the original.
> > git does not know about Change-Ids, but does know commmit-ids :)
> >
> 
> Change-ID captures all this information. You can know the patch in all
> branches with Change-ID, now that we are following same Change-ID across
> branches.

However a Change-Id is not standard git, it is purely a Gerrit thing. I
can't cherry-pick or 'git show' a Change-Id, but that works fine with a
git-commit.

I also like to give credits to the people that originally wrote and
reviewed the change. It is not required, but it is nice to have.

> > We should try to have all the needed details in the git repository, and
> > not rely on Gerrit for patch verification/checking. When I'm working on
> > a patch and wonder why/when something related was changed, I'll use the
> > local history, and do not want to depend on Gerrit.
> >
> 
> Change-ID is mentioned in the commit which is there in the git log, so we
> can figure out the information without needing internet/gerrit. So that
> part is not a problem.

Yes, of course I can figure it out, but it is additional work. Most
tools do not know about Change-Ids, like browsing through the code on
GitHub; a commit-id will be linked, a Change-Id not.

> All of this information was important to mention earlier because there was
> no common thing binding all together. With same Change-ID across branches
> for a patch, it seems unnecessary to mention this information in the commit
> message.

Not everyone is familiar with how Gerrit handles Change-Ids. A
git-commit is something that other (new) contributors understand better.
I prefer to make it as easy as possible for people to go through the git
log and compare/check/verify whatever they are looking for. Limiting
references to Change-Ids makes their task a little more difficult.

Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Pranith Kumar Karampuri 
On Fri, Jun 23, 2017 at 1:30 PM, Niels de Vos  wrote:

> On Fri, Jun 23, 2017 at 09:15:21AM +0530, Pranith Kumar Karampuri wrote:
> > hi,
> >  Now that we are doing backports with same Change-Id, we can find the
> > patches and their backports both online and in the tree without any extra
> > information in the commit message. So shall we stop adding text similar
> to:
> >
> > > Reviewed-on: https://review.gluster.org/17414
> > > Smoke: Gluster Build System 
> > > Reviewed-by: Pranith Kumar Karampuri 
> > > Tested-by: Pranith Kumar Karampuri 
> > > NetBSD-regression: NetBSD Build System 
> > > Reviewed-by: Amar Tumballi 
> > > CentOS-regression: Gluster Build System  >
> > (cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)
> >
> > in the patches?
> >
> > Do you see any other value from this information that I might be missing?
>
> I think it is good practise to mention where the backport comes from,
> who developed and reviewed the original. At least the commit-id is
> important, that way the backport can easily be compared to the original.
> git does not know about Change-Ids, but does know commmit-ids :)
>

Change-ID captures all this information. You can know the patch in all
branches with Change-ID, now that we are following same Change-ID across
branches.


>
> We should try to have all the needed details in the git repository, and
> not rely on Gerrit for patch verification/checking. When I'm working on
> a patch and wonder why/when something related was changed, I'll use the
> local history, and do not want to depend on Gerrit.
>

Change-ID is mentioned in the commit which is there in the git log, so we
can figure out the information without needing internet/gerrit. So that
part is not a problem.

All of this information was important to mention earlier because there was
no common thing binding all together. With same Change-ID across branches
for a patch, it seems unnecessary to mention this information in the commit
message.


> Thanks,
> Niels
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Niels de Vos 
On Fri, Jun 23, 2017 at 09:15:21AM +0530, Pranith Kumar Karampuri wrote:
> hi,
>  Now that we are doing backports with same Change-Id, we can find the
> patches and their backports both online and in the tree without any extra
> information in the commit message. So shall we stop adding text similar to:
> 
> > Reviewed-on: https://review.gluster.org/17414
> > Smoke: Gluster Build System 
> > Reviewed-by: Pranith Kumar Karampuri 
> > Tested-by: Pranith Kumar Karampuri 
> > NetBSD-regression: NetBSD Build System 
> > Reviewed-by: Amar Tumballi 
> > CentOS-regression: Gluster Build System 
> (cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)
> 
> in the patches?
> 
> Do you see any other value from this information that I might be missing?

I think it is good practise to mention where the backport comes from,
who developed and reviewed the original. At least the commit-id is
important, that way the backport can easily be compared to the original.
git does not know about Change-Ids, but does know commmit-ids :)

We should try to have all the needed details in the git repository, and
not rely on Gerrit for patch verification/checking. When I'm working on
a patch and wonder why/when something related was changed, I'll use the
local history, and do not want to depend on Gerrit.

Thanks,
Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-23 Thread Atin Mukherjee 
On Fri, Jun 23, 2017 at 9:37 AM, Ravishankar N 
wrote:

> On 06/23/2017 09:15 AM, Pranith Kumar Karampuri wrote:
>
> hi,
>  Now that we are doing backports with same Change-Id, we can find the
> patches and their backports both online and in the tree without any extra
> information in the commit message. So shall we stop adding text similar to:
>
> > Reviewed-on: https://review.gluster.org/17414
>
>
> Sometimes I combine 2 commits from master (typically commit 2 which fixes
> a bug in commit 1) in to a single patch while backporting. The change ID is
> not the same in that case and I explicitly mention the 2 patch urls in the
> squashed commit sent to the release branch.  So in those cases, some way to
> trace back to the patches in master is helpful. Otherwise I think it is
> fair to omit it.
>

IMHO, we should avoid doing this and keep it inline with mainline as much
as possible.


> > Smoke: Gluster Build System 
> > Reviewed-by: Pranith Kumar Karampuri 
> > Tested-by: Pranith Kumar Karampuri 
> > NetBSD-regression: NetBSD Build System 
> > Reviewed-by: Amar Tumballi 
> > CentOS-regression: Gluster Build System 
> (cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)
>
> in the patches?
>
> Do you see any other value from this information that I might be missing?
>
> --
> Pranith
>
>
> ___
> Gluster-devel mailing 
> listGluster-devel@gluster.orghttp://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-22 Thread Amar Tumballi 
On Fri, Jun 23, 2017 at 9:55 AM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Fri, Jun 23, 2017 at 9:37 AM, Ravishankar N 
> wrote:
>
>> On 06/23/2017 09:15 AM, Pranith Kumar Karampuri wrote:
>>
>> hi,
>>  Now that we are doing backports with same Change-Id, we can find the
>> patches and their backports both online and in the tree without any extra
>> information in the commit message. So shall we stop adding text similar to:
>>
>> > Reviewed-on: https://review.gluster.org/17414
>>
>>
>> Sometimes I combine 2 commits from master (typically commit 2 which fixes
>> a bug in commit 1) in to a single patch while backporting. The change ID is
>> not the same in that case and I explicitly mention the 2 patch urls in the
>> squashed commit sent to the release branch.  So in those cases, some way to
>> trace back to the patches in master is helpful. Otherwise I think it is
>> fair to omit it.
>>
>
> Ah! makes sense. Maybe for exceptions, let us use this but as a rule maybe
> it doesn't seem like a bad idea to omit. Let us also hear from others.
>

For easier one click approach, I guess, one can keep the 'Reviewed-on:'
line with URL. All other info is just extra bytes IMO.

-Amar


>
>
>> > Smoke: Gluster Build System 
>> > Reviewed-by: Pranith Kumar Karampuri 
>> > Tested-by: Pranith Kumar Karampuri 
>> > NetBSD-regression: NetBSD Build System 
>> > Reviewed-by: Amar Tumballi 
>> > CentOS-regression: Gluster Build System 
>> (cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)
>>
>> in the patches?
>>
>> Do you see any other value from this information that I might be missing?
>>
>> --
>> Pranith
>>
>>
>> ___
>> Gluster-devel mailing 
>> listGluster-devel@gluster.orghttp://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>>
>>
>
>
> --
> Pranith
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-22 Thread Pranith Kumar Karampuri 
On Fri, Jun 23, 2017 at 9:37 AM, Ravishankar N 
wrote:

> On 06/23/2017 09:15 AM, Pranith Kumar Karampuri wrote:
>
> hi,
>  Now that we are doing backports with same Change-Id, we can find the
> patches and their backports both online and in the tree without any extra
> information in the commit message. So shall we stop adding text similar to:
>
> > Reviewed-on: https://review.gluster.org/17414
>
>
> Sometimes I combine 2 commits from master (typically commit 2 which fixes
> a bug in commit 1) in to a single patch while backporting. The change ID is
> not the same in that case and I explicitly mention the 2 patch urls in the
> squashed commit sent to the release branch.  So in those cases, some way to
> trace back to the patches in master is helpful. Otherwise I think it is
> fair to omit it.
>

Ah! makes sense. Maybe for exceptions, let us use this but as a rule maybe
it doesn't seem like a bad idea to omit. Let us also hear from others.


> > Smoke: Gluster Build System 
> > Reviewed-by: Pranith Kumar Karampuri 
> > Tested-by: Pranith Kumar Karampuri 
> > NetBSD-regression: NetBSD Build System 
> > Reviewed-by: Amar Tumballi 
> > CentOS-regression: Gluster Build System 
> (cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)
>
> in the patches?
>
> Do you see any other value from this information that I might be missing?
>
> --
> Pranith
>
>
> ___
> Gluster-devel mailing 
> listGluster-devel@gluster.orghttp://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

2017-06-22 Thread Ravishankar N 

On 06/23/2017 09:15 AM, Pranith Kumar Karampuri wrote:

hi,
 Now that we are doing backports with same Change-Id, we can find 
the patches and their backports both online and in the tree without 
any extra information in the commit message. So shall we stop adding 
text similar to:


> Reviewed-on: https://review.gluster.org/17414


Sometimes I combine 2 commits from master (typically commit 2 which 
fixes a bug in commit 1) in to a single patch while backporting. The 
change ID is not the same in that case and I explicitly mention the 2 
patch urls in the squashed commit sent to the release branch.  So in 
those cases, some way to trace back to the patches in master is helpful. 
Otherwise I think it is fair to omit it.


> Smoke: Gluster Build System >
> Reviewed-by: Pranith Kumar Karampuri >
> Tested-by: Pranith Kumar Karampuri >
> NetBSD-regression: NetBSD Build System 
>
> Reviewed-by: Amar Tumballi >
> CentOS-regression: Gluster Build System 
>

(cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)

in the patches?

Do you see any other value from this information that I might be missing?

--
Pranith


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel



___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] reagarding backport information while porting patches

2017-06-22 Thread Pranith Kumar Karampuri 
hi,
 Now that we are doing backports with same Change-Id, we can find the
patches and their backports both online and in the tree without any extra
information in the commit message. So shall we stop adding text similar to:

> Reviewed-on: https://review.gluster.org/17414
> Smoke: Gluster Build System 
> Reviewed-by: Pranith Kumar Karampuri 
> Tested-by: Pranith Kumar Karampuri 
> NetBSD-regression: NetBSD Build System 
> Reviewed-by: Amar Tumballi 
> CentOS-regression: Gluster Build System 
(cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)

in the patches?

Do you see any other value from this information that I might be missing?

-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel