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 <sjl...@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 <ste...@hortonworks.com>
> wrote:
>
>>
>>> On 12 Nov 2015, at 17:49, Sangjin Lee <sjl...@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?
>>
