Re: following committer guideline when merging PR

[Vlad Rozov]

I cited both, in my first email I cited steps for a committer as it is a 
committer that verifies that a contribution meets a community 
guidelines. In reply back to Sanjay proposal, I cited part of the 
contribution guideline.


IMO, it is not that the wording around JIRA or any other part of the 
contribution guidelines has an ambiguity, both clearly state that JIRA 
must be updated by a contributor and if that was not done, it is a 
committer responsibility to enforce the update before a PR is merged.


Thank you,

Vlad

On 9/8/17 16:29, Pramod Immaneni wrote:

Vlad cited committer not contributor guidelines, maybe that is the source
of the confusion. If the wording in the contribution guidelines on the
website for contributor responsibilities around JIRA is the cause for the
ambiguity, let's fix it.

Thanks

On Fri, Sep 8, 2017 at 1:21 PM, Sanjay Pujare 
wrote:


May be you can help clear the confusion for me. From the contribution
guidelines you cited, it looks like it is already the contributor's
responsibility to ensure all JIRA fields are correct and update them when
the PR is merged.

But in your original email you cited apex-malhar PR 669 as an example where
the committer overlooked this responsibility. What am I missing?

On Fri, Sep 8, 2017 at 1:01 PM, Vlad Rozov  wrote:


Sanjay,

Please feel free to propose changes to the existing Apex contribution
guidelines, but prior to doing that I'd strongly recommend all community
members at least to review what already exists and to follow the

guidelines

[1]. Additionally, it will be good that the community members understand
how Apache Apex contribution and release processes work, and not simply
engage in voting without engaging into discussion and following existing
guidelines. All this is an indication that except for few individuals the
community is not mature and independent.

Thank you,

Vlad

[1] http://apex.apache.org/contributing.html

"Before starting work, have a JIRA assigned to yourself. If you want to
work on a ticket that is assigned to someone else, send a courtesy e-mail
to the assignee to check if you can take it over. Confirm type, priority
and other JIRA fields (often default values are not the best fit)."

On 9/8/17 11:37, Sanjay Pujare wrote:


Regarding updating JIRA (item#3) I think it should ideally be the
contributor's responsibility to update the JIRA with all the required
fields and not the committer's.

On Fri, Sep 8, 2017 at 11:25 AM, Vlad Rozov 

wrote:

item #3. The concern with #661 is with all items that I marked in red in

my first email.

Thank you,

Vlad

On 9/8/17 10:48, Pramod Immaneni wrote:

What's your concern with #669. It's a fix for a build issue (which you

created) and was approved by two committers. Wasn't getting builds to
successful state asap one of your top concerns based on your comments
and
-1 on #569 on core.

On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov 

wrote:

Committers,


Please make sure to follow Apex community guideline when merging PR
http://apex.apache.org/contributing.html.

1. Ensure that basic requirements for a pull request are met. This
  includes:
* Sufficient time has passed for others to review
* PR was suffiently reviewed and comments were addressed.
  Seevoting policy 

Re: following committer guideline when merging PR

[Pramod Immaneni]

Vlad cited committer not contributor guidelines, maybe that is the source
of the confusion. If the wording in the contribution guidelines on the
website for contributor responsibilities around JIRA is the cause for the
ambiguity, let's fix it.

Thanks

On Fri, Sep 8, 2017 at 1:21 PM, Sanjay Pujare 
wrote:

> May be you can help clear the confusion for me. From the contribution
> guidelines you cited, it looks like it is already the contributor's
> responsibility to ensure all JIRA fields are correct and update them when
> the PR is merged.
>
> But in your original email you cited apex-malhar PR 669 as an example where
> the committer overlooked this responsibility. What am I missing?
>
> On Fri, Sep 8, 2017 at 1:01 PM, Vlad Rozov  wrote:
>
> > Sanjay,
> >
> > Please feel free to propose changes to the existing Apex contribution
> > guidelines, but prior to doing that I'd strongly recommend all community
> > members at least to review what already exists and to follow the
> guidelines
> > [1]. Additionally, it will be good that the community members understand
> > how Apache Apex contribution and release processes work, and not simply
> > engage in voting without engaging into discussion and following existing
> > guidelines. All this is an indication that except for few individuals the
> > community is not mature and independent.
> >
> > Thank you,
> >
> > Vlad
> >
> > [1] http://apex.apache.org/contributing.html
> >
> > "Before starting work, have a JIRA assigned to yourself. If you want to
> > work on a ticket that is assigned to someone else, send a courtesy e-mail
> > to the assignee to check if you can take it over. Confirm type, priority
> > and other JIRA fields (often default values are not the best fit)."
> >
> > On 9/8/17 11:37, Sanjay Pujare wrote:
> >
> >> Regarding updating JIRA (item#3) I think it should ideally be the
> >> contributor's responsibility to update the JIRA with all the required
> >> fields and not the committer's.
> >>
> >> On Fri, Sep 8, 2017 at 11:25 AM, Vlad Rozov 
> wrote:
> >>
> >> item #3. The concern with #661 is with all items that I marked in red in
> >>> my first email.
> >>>
> >>> Thank you,
> >>>
> >>> Vlad
> >>>
> >>> On 9/8/17 10:48, Pramod Immaneni wrote:
> >>>
> >>> What's your concern with #669. It's a fix for a build issue (which you
>  created) and was approved by two committers. Wasn't getting builds to
>  successful state asap one of your top concerns based on your comments
>  and
>  -1 on #569 on core.
> 
>  On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov 
> wrote:
> 
>  Committers,
> 
> > Please make sure to follow Apex community guideline when merging PR
> > http://apex.apache.org/contributing.html.
> >
> > 1. Ensure that basic requirements for a pull request are met. This
> >  includes:
> >* Sufficient time has passed for others to review
> >* PR was suffiently reviewed and comments were addressed.
> >  Seevoting policy  > tion/voting.html
> >
> >> .
> >>
> >* When there are multiple reviewers, wait till other reviewers
> >  approve, with timeout of 48 hours before merging
> >* /If the PR was open for a long time, email dev@ declaring
> > intent
> >  to merge/
> >* Commit messages and PR title need to reference JIRA (pull
> >  requests will be linked to ticket)
> >* /Travis CI and Jenkins pull request build needs to pass/
> >* /Ensure tests are added/modified for new features or fixes/
> >* Ensure appropriate JavaDoc comments have been added
> >* Verify contributions don't depend on incompatible licences
> >  (seehttps://www.apache.org/legal/resolved.html#category-x)
> > 2. Use the github/rebase and merge/option or the git command line to
> >  merge the pull request (see link|view command line options|on
> the
> > PR).
> > 3. /Update JIRA after pushing the changes. Set the|Fix
> >  version|field and resolve the JIRA with proper resolution.
> > *Also
> >  verify that other fields (type, priority, assignee) are
> correct*./
> >
> >
> > A couple of recent PR merges (#661, #669) to apex-malhar require a
> > second
> > look from the committers.
> >
> > Thank you,
> >
> > Vlad
> >
> >
> >
> >
>

Re: following committer guideline when merging PR

[Vlad Rozov]

I'll repeat myself. Prior to suggesting new process, posting questions 
to dev@apex or voting, please take time to review existing 
documentation, discussion threads and the information posted on 
apex.apache.org.


To answer your question regarding PR 669 - it is the committer 
responsibility to change the status of JIRA and update "Fix version" 
once PR is merged. If you want to revisit this requirement, please 
provide a justification/reason(s) why and how new process will be better 
than the existing one.


Thank you,

Vlad

On 9/8/17 13:21, Sanjay Pujare wrote:

May be you can help clear the confusion for me. From the contribution
guidelines you cited, it looks like it is already the contributor's
responsibility to ensure all JIRA fields are correct and update them when
the PR is merged.

But in your original email you cited apex-malhar PR 669 as an example where
the committer overlooked this responsibility. What am I missing?

On Fri, Sep 8, 2017 at 1:01 PM, Vlad Rozov  wrote:


Sanjay,

Please feel free to propose changes to the existing Apex contribution
guidelines, but prior to doing that I'd strongly recommend all community
members at least to review what already exists and to follow the guidelines
[1]. Additionally, it will be good that the community members understand
how Apache Apex contribution and release processes work, and not simply
engage in voting without engaging into discussion and following existing
guidelines. All this is an indication that except for few individuals the
community is not mature and independent.

Thank you,

Vlad

[1] http://apex.apache.org/contributing.html

"Before starting work, have a JIRA assigned to yourself. If you want to
work on a ticket that is assigned to someone else, send a courtesy e-mail
to the assignee to check if you can take it over. Confirm type, priority
and other JIRA fields (often default values are not the best fit)."

On 9/8/17 11:37, Sanjay Pujare wrote:


Regarding updating JIRA (item#3) I think it should ideally be the
contributor's responsibility to update the JIRA with all the required
fields and not the committer's.

On Fri, Sep 8, 2017 at 11:25 AM, Vlad Rozov  wrote:

item #3. The concern with #661 is with all items that I marked in red in

my first email.

Thank you,

Vlad

On 9/8/17 10:48, Pramod Immaneni wrote:

What's your concern with #669. It's a fix for a build issue (which you

created) and was approved by two committers. Wasn't getting builds to
successful state asap one of your top concerns based on your comments
and
-1 on #569 on core.

On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov  wrote:

Committers,


Please make sure to follow Apex community guideline when merging PR
http://apex.apache.org/contributing.html.

1. Ensure that basic requirements for a pull request are met. This
  includes:
* Sufficient time has passed for others to review
* PR was suffiently reviewed and comments were addressed.
  Seevoting policy 

Re: following committer guideline when merging PR

[Sanjay Pujare]

May be you can help clear the confusion for me. From the contribution
guidelines you cited, it looks like it is already the contributor's
responsibility to ensure all JIRA fields are correct and update them when
the PR is merged.

But in your original email you cited apex-malhar PR 669 as an example where
the committer overlooked this responsibility. What am I missing?

On Fri, Sep 8, 2017 at 1:01 PM, Vlad Rozov  wrote:

> Sanjay,
>
> Please feel free to propose changes to the existing Apex contribution
> guidelines, but prior to doing that I'd strongly recommend all community
> members at least to review what already exists and to follow the guidelines
> [1]. Additionally, it will be good that the community members understand
> how Apache Apex contribution and release processes work, and not simply
> engage in voting without engaging into discussion and following existing
> guidelines. All this is an indication that except for few individuals the
> community is not mature and independent.
>
> Thank you,
>
> Vlad
>
> [1] http://apex.apache.org/contributing.html
>
> "Before starting work, have a JIRA assigned to yourself. If you want to
> work on a ticket that is assigned to someone else, send a courtesy e-mail
> to the assignee to check if you can take it over. Confirm type, priority
> and other JIRA fields (often default values are not the best fit)."
>
> On 9/8/17 11:37, Sanjay Pujare wrote:
>
>> Regarding updating JIRA (item#3) I think it should ideally be the
>> contributor's responsibility to update the JIRA with all the required
>> fields and not the committer's.
>>
>> On Fri, Sep 8, 2017 at 11:25 AM, Vlad Rozov  wrote:
>>
>> item #3. The concern with #661 is with all items that I marked in red in
>>> my first email.
>>>
>>> Thank you,
>>>
>>> Vlad
>>>
>>> On 9/8/17 10:48, Pramod Immaneni wrote:
>>>
>>> What's your concern with #669. It's a fix for a build issue (which you
 created) and was approved by two committers. Wasn't getting builds to
 successful state asap one of your top concerns based on your comments
 and
 -1 on #569 on core.

 On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov  wrote:

 Committers,

> Please make sure to follow Apex community guideline when merging PR
> http://apex.apache.org/contributing.html.
>
> 1. Ensure that basic requirements for a pull request are met. This
>  includes:
>* Sufficient time has passed for others to review
>* PR was suffiently reviewed and comments were addressed.
>  Seevoting policy  tion/voting.html
>
>> .
>>
>* When there are multiple reviewers, wait till other reviewers
>  approve, with timeout of 48 hours before merging
>* /If the PR was open for a long time, email dev@ declaring
> intent
>  to merge/
>* Commit messages and PR title need to reference JIRA (pull
>  requests will be linked to ticket)
>* /Travis CI and Jenkins pull request build needs to pass/
>* /Ensure tests are added/modified for new features or fixes/
>* Ensure appropriate JavaDoc comments have been added
>* Verify contributions don't depend on incompatible licences
>  (seehttps://www.apache.org/legal/resolved.html#category-x)
> 2. Use the github/rebase and merge/option or the git command line to
>  merge the pull request (see link|view command line options|on the
> PR).
> 3. /Update JIRA after pushing the changes. Set the|Fix
>  version|field and resolve the JIRA with proper resolution.
> *Also
>  verify that other fields (type, priority, assignee) are correct*./
>
>
> A couple of recent PR merges (#661, #669) to apex-malhar require a
> second
> look from the committers.
>
> Thank you,
>
> Vlad
>
>
>
>

Re: following committer guideline when merging PR

[Vlad Rozov]

Sanjay,

Please feel free to propose changes to the existing Apex contribution 
guidelines, but prior to doing that I'd strongly recommend all community 
members at least to review what already exists and to follow the 
guidelines [1]. Additionally, it will be good that the community members 
understand how Apache Apex contribution and release processes work, and 
not simply engage in voting without engaging into discussion and 
following existing guidelines. All this is an indication that except for 
few individuals the community is not mature and independent.


Thank you,

Vlad

[1] http://apex.apache.org/contributing.html

"Before starting work, have a JIRA assigned to yourself. If you want to 
work on a ticket that is assigned to someone else, send a courtesy 
e-mail to the assignee to check if you can take it over. Confirm type, 
priority and other JIRA fields (often default values are not the best fit)."


On 9/8/17 11:37, Sanjay Pujare wrote:

Regarding updating JIRA (item#3) I think it should ideally be the
contributor's responsibility to update the JIRA with all the required
fields and not the committer's.

On Fri, Sep 8, 2017 at 11:25 AM, Vlad Rozov  wrote:


item #3. The concern with #661 is with all items that I marked in red in
my first email.

Thank you,

Vlad

On 9/8/17 10:48, Pramod Immaneni wrote:


What's your concern with #669. It's a fix for a build issue (which you
created) and was approved by two committers. Wasn't getting builds to
successful state asap one of your top concerns based on your comments and
-1 on #569 on core.

On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov  wrote:

Committers,

Please make sure to follow Apex community guideline when merging PR
http://apex.apache.org/contributing.html.

1. Ensure that basic requirements for a pull request are met. This
 includes:
   * Sufficient time has passed for others to review
   * PR was suffiently reviewed and comments were addressed.
 Seevoting policy 

Re: following committer guideline when merging PR

[Sanjay Pujare]

Regarding updating JIRA (item#3) I think it should ideally be the
contributor's responsibility to update the JIRA with all the required
fields and not the committer's.

On Fri, Sep 8, 2017 at 11:25 AM, Vlad Rozov  wrote:

> item #3. The concern with #661 is with all items that I marked in red in
> my first email.
>
> Thank you,
>
> Vlad
>
> On 9/8/17 10:48, Pramod Immaneni wrote:
>
>> What's your concern with #669. It's a fix for a build issue (which you
>> created) and was approved by two committers. Wasn't getting builds to
>> successful state asap one of your top concerns based on your comments and
>> -1 on #569 on core.
>>
>> On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov  wrote:
>>
>> Committers,
>>>
>>> Please make sure to follow Apex community guideline when merging PR
>>> http://apex.apache.org/contributing.html.
>>>
>>> 1. Ensure that basic requirements for a pull request are met. This
>>> includes:
>>>   * Sufficient time has passed for others to review
>>>   * PR was suffiently reviewed and comments were addressed.
>>> Seevoting policy >> >.
>>>   * When there are multiple reviewers, wait till other reviewers
>>> approve, with timeout of 48 hours before merging
>>>   * /If the PR was open for a long time, email dev@ declaring intent
>>> to merge/
>>>   * Commit messages and PR title need to reference JIRA (pull
>>> requests will be linked to ticket)
>>>   * /Travis CI and Jenkins pull request build needs to pass/
>>>   * /Ensure tests are added/modified for new features or fixes/
>>>   * Ensure appropriate JavaDoc comments have been added
>>>   * Verify contributions don't depend on incompatible licences
>>> (seehttps://www.apache.org/legal/resolved.html#category-x)
>>> 2. Use the github/rebase and merge/option or the git command line to
>>> merge the pull request (see link|view command line options|on the
>>> PR).
>>> 3. /Update JIRA after pushing the changes. Set the|Fix
>>> version|field and resolve the JIRA with proper resolution. *Also
>>> verify that other fields (type, priority, assignee) are correct*./
>>>
>>>
>>> A couple of recent PR merges (#661, #669) to apex-malhar require a second
>>> look from the committers.
>>>
>>> Thank you,
>>>
>>> Vlad
>>>
>>>
>

Re: following committer guideline when merging PR

[Vlad Rozov]

item #3. The concern with #661 is with all items that I marked in red in 
my first email.


Thank you,

Vlad

On 9/8/17 10:48, Pramod Immaneni wrote:

What's your concern with #669. It's a fix for a build issue (which you
created) and was approved by two committers. Wasn't getting builds to
successful state asap one of your top concerns based on your comments and
-1 on #569 on core.

On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov  wrote:


Committers,

Please make sure to follow Apex community guideline when merging PR
http://apex.apache.org/contributing.html.

1. Ensure that basic requirements for a pull request are met. This
includes:
  * Sufficient time has passed for others to review
  * PR was suffiently reviewed and comments were addressed.
Seevoting policy .
  * When there are multiple reviewers, wait till other reviewers
approve, with timeout of 48 hours before merging
  * /If the PR was open for a long time, email dev@ declaring intent
to merge/
  * Commit messages and PR title need to reference JIRA (pull
requests will be linked to ticket)
  * /Travis CI and Jenkins pull request build needs to pass/
  * /Ensure tests are added/modified for new features or fixes/
  * Ensure appropriate JavaDoc comments have been added
  * Verify contributions don't depend on incompatible licences
(seehttps://www.apache.org/legal/resolved.html#category-x)
2. Use the github/rebase and merge/option or the git command line to
merge the pull request (see link|view command line options|on the PR).
3. /Update JIRA after pushing the changes. Set the|Fix
version|field and resolve the JIRA with proper resolution. *Also
verify that other fields (type, priority, assignee) are correct*./


A couple of recent PR merges (#661, #669) to apex-malhar require a second
look from the committers.

Thank you,

Vlad

Re: following committer guideline when merging PR

[Pramod Immaneni]

What's your concern with #669. It's a fix for a build issue (which you
created) and was approved by two committers. Wasn't getting builds to
successful state asap one of your top concerns based on your comments and
-1 on #569 on core.

On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov  wrote:

> Committers,
>
> Please make sure to follow Apex community guideline when merging PR
> http://apex.apache.org/contributing.html.
>
> 1. Ensure that basic requirements for a pull request are met. This
>includes:
>  * Sufficient time has passed for others to review
>  * PR was suffiently reviewed and comments were addressed.
>Seevoting policy .
>  * When there are multiple reviewers, wait till other reviewers
>approve, with timeout of 48 hours before merging
>  * /If the PR was open for a long time, email dev@ declaring intent
>to merge/
>  * Commit messages and PR title need to reference JIRA (pull
>requests will be linked to ticket)
>  * /Travis CI and Jenkins pull request build needs to pass/
>  * /Ensure tests are added/modified for new features or fixes/
>  * Ensure appropriate JavaDoc comments have been added
>  * Verify contributions don't depend on incompatible licences
>(seehttps://www.apache.org/legal/resolved.html#category-x)
> 2. Use the github/rebase and merge/option or the git command line to
>merge the pull request (see link|view command line options|on the PR).
> 3. /Update JIRA after pushing the changes. Set the|Fix
>version|field and resolve the JIRA with proper resolution. *Also
>verify that other fields (type, priority, assignee) are correct*./
>
>
> A couple of recent PR merges (#661, #669) to apex-malhar require a second
> look from the committers.
>
> Thank you,
>
> Vlad
>

Re: following committer guideline when merging PR

[Amol Kekre]

Make sense. +1

Thks
Amol


E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov  wrote:

> Committers,
>
> Please make sure to follow Apex community guideline when merging PR
> http://apex.apache.org/contributing.html.
>
> 1. Ensure that basic requirements for a pull request are met. This
>includes:
>  * Sufficient time has passed for others to review
>  * PR was suffiently reviewed and comments were addressed.
>Seevoting policy .
>  * When there are multiple reviewers, wait till other reviewers
>approve, with timeout of 48 hours before merging
>  * /If the PR was open for a long time, email dev@ declaring intent
>to merge/
>  * Commit messages and PR title need to reference JIRA (pull
>requests will be linked to ticket)
>  * /Travis CI and Jenkins pull request build needs to pass/
>  * /Ensure tests are added/modified for new features or fixes/
>  * Ensure appropriate JavaDoc comments have been added
>  * Verify contributions don't depend on incompatible licences
>(seehttps://www.apache.org/legal/resolved.html#category-x)
> 2. Use the github/rebase and merge/option or the git command line to
>merge the pull request (see link|view command line options|on the PR).
> 3. /Update JIRA after pushing the changes. Set the|Fix
>version|field and resolve the JIRA with proper resolution. *Also
>verify that other fields (type, priority, assignee) are correct*./
>
>
> A couple of recent PR merges (#661, #669) to apex-malhar require a second
> look from the committers.
>
> Thank you,
>
> Vlad
>

Re: following committer guideline when merging PR

[Amol Kekre]

Make sense. +1

Thks
Amol


E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov  wrote:

> Committers,
>
> Please make sure to follow Apex community guideline when merging PR
> http://apex.apache.org/contributing.html.
>
> 1. Ensure that basic requirements for a pull request are met. This
>includes:
>  * Sufficient time has passed for others to review
>  * PR was suffiently reviewed and comments were addressed.
>Seevoting policy .
>  * When there are multiple reviewers, wait till other reviewers
>approve, with timeout of 48 hours before merging
>  * /If the PR was open for a long time, email dev@ declaring intent
>to merge/
>  * Commit messages and PR title need to reference JIRA (pull
>requests will be linked to ticket)
>  * /Travis CI and Jenkins pull request build needs to pass/
>  * /Ensure tests are added/modified for new features or fixes/
>  * Ensure appropriate JavaDoc comments have been added
>  * Verify contributions don't depend on incompatible licences
>(seehttps://www.apache.org/legal/resolved.html#category-x)
> 2. Use the github/rebase and merge/option or the git command line to
>merge the pull request (see link|view command line options|on the PR).
> 3. /Update JIRA after pushing the changes. Set the|Fix
>version|field and resolve the JIRA with proper resolution. *Also
>verify that other fields (type, priority, assignee) are correct*./
>
>
> A couple of recent PR merges (#661, #669) to apex-malhar require a second
> look from the committers.
>
> Thank you,
>
> Vlad
>

following committer guideline when merging PR

[Vlad Rozov]

Committers,

Please make sure to follow Apex community guideline when merging PR 
http://apex.apache.org/contributing.html.


1. Ensure that basic requirements for a pull request are met. This
   includes:
 * Sufficient time has passed for others to review
 * PR was suffiently reviewed and comments were addressed.
   Seevoting policy .
 * When there are multiple reviewers, wait till other reviewers
   approve, with timeout of 48 hours before merging
 * /If the PR was open for a long time, email dev@ declaring intent
   to merge/
 * Commit messages and PR title need to reference JIRA (pull
   requests will be linked to ticket)
 * /Travis CI and Jenkins pull request build needs to pass/
 * /Ensure tests are added/modified for new features or fixes/
 * Ensure appropriate JavaDoc comments have been added
 * Verify contributions don't depend on incompatible licences
   (seehttps://www.apache.org/legal/resolved.html#category-x)
2. Use the github/rebase and merge/option or the git command line to
   merge the pull request (see link|view command line options|on the PR).
3. /Update JIRA after pushing the changes. Set the|Fix
   version|field and resolve the JIRA with proper resolution. *Also
   verify that other fields (type, priority, assignee) are correct*./


A couple of recent PR merges (#661, #669) to apex-malhar require a 
second look from the committers.


Thank you,

Vlad