Hello,
Typically when a pull request is accepted for a JIRA issue, can I close the JIRA or should I wait for pull request reviewer to close the issue. it's done differently in various teams/projects. Just would like to know how it's done here in Flink project so that I can follow for future pull requests. Thanks, Lokesh |
Hey Lokesh,
The implicit practice is that the committer merging you PR closes the JIRA. Please do not close the JIRA, before your patch is merged. If the committer forgets to close it after your code is in you are very welcome to close it yourself. Best, Marton On Fri, Jun 5, 2015 at 5:24 PM, Lokesh Rajaram <[hidden email]> wrote: > Hello, > > Typically when a pull request is accepted for a JIRA issue, can I close the > JIRA or should I wait for pull request reviewer to close the issue. it's > done differently in various teams/projects. Just would like to know how > it's done here in Flink project so that I can follow for future pull > requests. > > Thanks, > Lokesh > |
Thanks Marton.
On Fri, Jun 5, 2015 at 8:29 AM, Márton Balassi <[hidden email]> wrote: > Hey Lokesh, > > The implicit practice is that the committer merging you PR closes the JIRA. > Please do not close the JIRA, before your patch is merged. If the committer > forgets to close it after your code is in you are very welcome to close it > yourself. > > Best, > > Marton > > On Fri, Jun 5, 2015 at 5:24 PM, Lokesh Rajaram <[hidden email]> > wrote: > > > Hello, > > > > Typically when a pull request is accepted for a JIRA issue, can I close > the > > JIRA or should I wait for pull request reviewer to close the issue. it's > > done differently in various teams/projects. Just would like to know how > > it's done here in Flink project so that I can follow for future pull > > requests. > > > > Thanks, > > Lokesh > > > |
In reply to this post by Lokesh Rajaram
Hi Lokesh,
It depends. If you created the issue and submitted the pull request, then you are free to close the issue. A reviewer or another committer might actually mark the issue as resolved beforehand because he thinks that everything is fixed. However, only the original reporter should close the issue as that implies that the issue has really been fixed and no more work is required. So if you are not the creator of the issue, feel free to resolve the issue after your pull request has been merged. Resolving and closing might seem similar but there is a subtle difference. Cheers, Max On Fri, Jun 5, 2015 at 5:24 PM, Lokesh Rajaram <[hidden email]> wrote: > Hello, > > Typically when a pull request is accepted for a JIRA issue, can I close the > JIRA or should I wait for pull request reviewer to close the issue. it's > done differently in various teams/projects. Just would like to know how > it's done here in Flink project so that I can follow for future pull > requests. > > Thanks, > Lokesh > |
Got it. Thanks for detailed explanation.
On Fri, Jun 5, 2015 at 8:34 AM, Maximilian Michels <[hidden email]> wrote: > Hi Lokesh, > > It depends. If you created the issue and submitted the pull request, then > you are free to close the issue. A reviewer or another committer might > actually mark the issue as resolved beforehand because he thinks that > everything is fixed. However, only the original reporter should close the > issue as that implies that the issue has really been fixed and no more work > is required. > > So if you are not the creator of the issue, feel free to resolve the issue > after your pull request has been merged. Resolving and closing might seem > similar but there is a subtle difference. > > Cheers, > Max > > On Fri, Jun 5, 2015 at 5:24 PM, Lokesh Rajaram <[hidden email]> > wrote: > > > Hello, > > > > Typically when a pull request is accepted for a JIRA issue, can I close > the > > JIRA or should I wait for pull request reviewer to close the issue. it's > > done differently in various teams/projects. Just would like to know how > > it's done here in Flink project so that I can follow for future pull > > requests. > > > > Thanks, > > Lokesh > > > |
Free forum by Nabble | Edit this page |