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