hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Subject Re: Need for force-push on feature branches
Date Thu, 12 Nov 2015 18:08:43 GMT

Implementing project-specific patch identification rules are definitely ‘not trivial’.

FWIW, the documented ruleset Yetus supports is here: 

	https://yetus.apache.org/documentation/latest/precommit-patchnames/

(Altho, in reality, the code does support more than this but they are sort of weird looking,
etc.)

> On Nov 12, 2015, at 10:04 AM, Sangjin Lee <sjlee0@gmail.com> wrote:
> 
> I suppose that would be fine too. Yetus just needs to add "feature/" to the
> git branch name when it fails to find it as is. So it would require a
> little work on yetus, but I guess should be pretty trivial?
> 
> On Thu, Nov 12, 2015 at 9:59 AM, Steve Loughran <stevel@hortonworks.com>
> wrote:
> 
>> 
>>> On 12 Nov 2015, at 17:49, Sangjin Lee <sjlee0@gmail.com> wrote:
>>> 
>>> Yes, I completely understand about the git branch naming practice (in
>> fact
>>> that's what I normally do). I was commenting on our hadoop patch naming
>>> convention. We are supposed to use patch names as
>>> "<jira-id>-<branch-name-if-not-trunk>.<sequence>.patch".
>>> 
>>> If we used "feature/HADOOP-12345" as the git branch name and the subtask
>>> JIRA was HADOOP-67890 for example, the patch file name would be
>>> "HADOOP-67890-feature/HADOOP-12345.001.patch", which would not be doable,
>>> no? For that to work, we would need to have some kind of escaping
>>> convention which jenkins and users follow.
>>> 
>> 
>> aah, now I follow. wouldn't HADOOP-12345.001.patch be enough?
>> 


Mime
View raw message