yetus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: RDM, precommit, and Patch Available JIRAs
Date Mon, 01 May 2017 22:58:27 GMT
Pinging this thread, this problem is becoming more acute for Hadoop since
we have multiple releases in flight.

Any thoughts on the proposal? The goal is that this would allow manually
triggering test-patch on a JIRA that is not Patch Available. The automatic
runs would still look only for the PA status.

On Thu, Jan 5, 2017 at 1:18 PM, Andrew Wang <andrew.wang@cloudera.com>
wrote:

> Hi Ajay,
>
> I think you captured it, but I'll explain once more to be sure:
>
> * RDM looks for JIRAs resolved as "Fixed" when making the release notes
> * In the Hadoop dev workflow, sometimes patch is committed to a branch,
> then there's a delay before it's backported to another branch.
> * We want to run precommit on the backported patch, and the precommit
> script requires the JIRA to be open and in "Patch Available" status.
>
> Thus, until the JIRA is fully backported, it needs to be open and "Patch
> Available". RDM won't pick up these JIRAs for any fix version since they're
> not in "Fixed" state. This means the release notes will be incomplete, and
> we can't do a release.
>
> Getting back to the proposals, I suggested relaxing either RDM or
> precommit to be more permissive as to the JIRA status. Thinking about it
> more, I'd prefer to relax precommit, since relaxing RDM means we
> potentially need to edit a lot of JIRA fix versions. There's also value
> from having a fix version set even for JIRAs not resolved as "Fixed" (e.g.
> "Duplicate").
>
> Filing an additional JIRA for any unclean backport introduces overhead to
> the happy path and complicates tracking, so I'm not a fan.
>
> We've never been able to avoid typos in commit messages, so we don't have
> a reliable mapping from git log -> JIRAs. I don't think RDM wants to be in
> the business of trying to solve this either.
>
> Best,
> Andrew
>
> On Thu, Jan 5, 2017 at 12:35 PM, Ajay Yadava <ajayyadavaatos@gmail.com>
> wrote:
>
>> I am not sure if I understand the problem that you are facing or your
>> proposal completely, so please feel free to correct me.
>>
>> I think what Allen has suggested is perhaps the best way to workaround
>> this
>> problem. However, if for some reason that's not possible/desirable, then
>> one option may be to fall back to git commit log to determine the true
>> status of such issues i.e. if apart from target release version, an open
>> JIRA has other versions also in fix-versions field of JIRA, then it means
>> it *may* be committed to the branch. So for such cases, we check commit
>> log
>> of the branch for such cases.
>>
>> However, this requires a way to identify the commit for the JIRA e.g. by
>> assuming a convention of mentioning JIRA ID in the commit message.
>>
>> Are you suggesting this change in RDM or proposing another script to
>> identify such JIRAs? Or did I misunderstood the issue completely?
>>
>> Regards
>> Ajay Yadava
>>
>> On Wed, Jan 4, 2017 at 4:11 PM Andrew Wang <andrew.wang@cloudera.com>
>> wrote:
>>
>> On Wed, Jan 4, 2017 at 1:07 PM, Andrew Wang <andrew.wang@cloudera.com>
>> wrote:
>>
>> >
>> > On Wed, Jan 4, 2017 at 12:58 PM, Allen Wittenauer <
>> > aw@effectivemachines.com> wrote:
>> >
>> >>
>> >> > On Jan 4, 2017, at 12:00 PM, Andrew Wang <andrew.wang@cloudera.com>
>> >> wrote:
>> >> >
>> >> > Thoughts?
>> >>
>> >>         If a back port is taking that long, it's probably better to
>> open
>> >> another JIRA for it.
>> >>
>> >> It's not that any individual backport takes that long, but there are
>> > enough patches flying around that there's always at least one JIRA in
>> this
>> > state.
>> >
>> > My goal is for the branch (and JIRA) to always be in a releaseable
>> state.
>> >
>>
>> BTW, one example is that I wrote a script to reconcile JIRA information
>> with git state. I'd like to turn on an email when the tool detects an
>> error, but it's never passed successfully due to the above issue.
>>
>> https://builds.apache.org/view/H-L/view/Hadoop/job/Hadoop-trunk-versions/
>>
>> --
>> Regards
>> Ajay Yadava
>>
>
>

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