hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kumar Vavilapalli <vino...@hortonworks.com>
Subject Re: Creating branch-1
Date Wed, 03 Jun 2015 19:17:25 GMT
Hadoop uses a "Target Version" field. Not sure if this was done for all projects.

+Vinod

On Jun 3, 2015, at 9:16 AM, Alan Gates <alanfgates@gmail.com<mailto:alanfgates@gmail.com>>
wrote:

I don't think using Affects Version will work because it is used to list which versions of
Hive the bug affects, unless you're proposing being able to parse affected version into branch
(ie 1.3.0 => branch-1).

I like the idea of customizing JIRA, though I don't know how hard it is.

We could also use the labels field.  It would run against master by default and you could
also add a label to run against an additional branch.  It would have to find a patch matching
that branch in order to run.

Alan.

[cid:part1.08000808.03000103@gmail.com]
Thejas Nair<mailto:thejas.nair@gmail.com>
June 3, 2015 at 7:51
Thanks for the insights Sergio!
Using 'Affects Version' sounds like a good idea. However, for the case
where it needs to be executed against both branch-1 and master, I
think it would be more intuitive to use
"Affects Version/s: branch-master branch-1 " , as the version
number in master branch will keep increasing.

We might be able to request for a custom field in jira (say "Test
branches") for this as well. But we could probably start with the
'Affects Version' approach.
[cid:part1.08000808.03000103@gmail.com]
Sergio Pena<mailto:sergio.pena@cloudera.com>
June 2, 2015 at 15:03
Hi Alan,

Currently, the test system executes tests on a specific branch only if
there is a Jenkins job assigned to it, like trunk or spark. Any other
branch will not work. We will need to create a job for branch-1, modify the
jenkins-submit-build.sh to add the new profile, and add a new properties
file to the Jenkins instance that contains branch information.

This is a little tedious for every branch we create.

Also, I don't think the test system will grab two patches (branch-1 &
master) to execute the tests on different branches. It will get the latest
one you uploaded.

What about if we use the 'Affects Version/s' field of the ticket to specify
which branches the patch needs to be executed? Or as you said, use hints on
the comments.

For instance:
- Affects Version/s: branch-1 # Tests on branch-1 only
- Affects Version/s: 2.0.0 branch-1 # Tests on branch-1 and master
- Affects Version/s: branch-spark # Tests on branch-spark only

If we use 'branch-xxx' as a naming convention for our branches, then we can
detect the branch from the ticket details. And if x.x.x version is
specified, then just execute them from master.

Also, branch-1 would need to be executed with MR1, right? Then the patch
file would need to be named 'HIVE-XXXX-mr1.patch' so that it uses the MR1
environment.

Right now the code that parses this info is on process_jira function on
'jenkins-common.sh', and it is called by 'jenkins-submit-build.sh'. We can
parse different branches there, and let jenkins-submit-build.sh call the
correct job with specific branch details.

Any other ideas?

- Sergio



[cid:part1.08000808.03000103@gmail.com]
Alan Gates<mailto:alanfgates@gmail.com>
June 1, 2015 at 16:19
Based on our discussion and vote last week I'm working on creating branch-1.   I plan to make
the branch tomorrow.  If anyone has a large commit they don't want to have to commit twice
and they are close to committing it let me know so I can make sure it gets in before I branch.

I'll also be updating https://cwiki.apache.org/confluence/display/Hive/HowToContribute to
clarify how to handle feature and bug fix patches on master and branch-1.

Also, we will need to make sure patches can be tested against master and branch-1.  If I understand
correctly the test system today will run a patch against a branch instead of master if the
patch is named with the branch name.  There are a couple of issues with this.  One, people
will often want to submit two versions of patches and have them both tested (one against master
and one against branch-1) rather than one or the other.  The second is we will want a way
for one patch to be tested against both when appropriate.  The first case could be handled
by the system picking up both branch-1 and master patches and running them automatically.
 The second could be handled by hints in the comments so the system needs to run both.  I'm
open to other suggestions as well.  Can someone familiar with the testing code point to where
I'd look to see what it would take to make this work?

Alan.


Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message