hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sangjin Lee <sjl...@gmail.com>
Subject Re: Need for force-push on feature branches
Date Thu, 12 Nov 2015 18:14:21 GMT
I don't think we're proposing project-specific rules. It would be a
recognition of the git branch name prefix "feature/".

If the file name had "HADOOP-67890-HADOOP-12345.001.patch" where
HADOOP-12345 was the feature JIRA but the git branch was
"feature/HADOOP-12345", if yetus didn't find a branch named "HADOOP-12345",
can it also look for "feature/HADOOP-12345" before failing the build?
HADOOP-12345 can be any branch JIRA.

On Thu, Nov 12, 2015 at 10:08 AM, Allen Wittenauer <aw@altiscale.com> wrote:

>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message