I believe that there are too many scenarios that we have to cover if we are to design a generic approach. Common pattern I've seen most times is when assignee on the ticket, who's usually author of relevant PR, is expected to either resolve ticket or pass it to the feature owner for verification.
We can have a bot that will check stale assigned tickets and poke assignees. Can go further and allow bot to unassign tickets if no response comes and remove "triaged" label. This will always highlight all non-updated tickets and keep forgotten tickets in available pool. Giving a hint to pass ownership of ticket to committer (or person who merged PR) can be a simple answer for contributors who are not sure whether ticket can be closed. --Mikhail Have feedback <http://go/migryz-feedback>? On Wed, Mar 13, 2019 at 6:00 PM Michael Luckey <adude3...@gmail.com> wrote: > Totally agree. The contributor is most likely be the better target. But as > she is probably less familiar with the process, we might be better of to > put the responsibility on the committer to kindly ask/discuss with her how > to proceed with corresponding jira ticket? > > On Thu, Mar 14, 2019 at 1:18 AM Ahmet Altay <al...@google.com> wrote: > >> I agree with defining the workflow for closing JIRAs. Would not >> contributor be in a better position to close JIRAs or keep it open? It >> would make sense for the committer to ask about this but I think >> contributor (presumably the person who is the assignee of the JIRA) could >> be the responsible party for updating their JIRAs. On the other hand, I >> understand the argument that committer could do this at the time of merging >> and fill a gap in the process. >> >> On Wed, Mar 13, 2019 at 4:59 PM Michael Luckey <adude3...@gmail.com> >> wrote: >> >>> Hi, >>> >>> definitely +1 to properly establish a workflow to maintain jira status. >>> Naively I d think, the reporter should close as she is the one to confirm >>> whether the reported issue is fixed or not. But for obvious reasons that >>> will not work here, so - although it puts another burden on committers, you >>> are probably right that the committer is the best choice to ensure that the >>> ticket gets promoted. Whether it will be resolved or clarified what's still >>> to be done. >>> >>> Looking into the current state, we seem to have tons of issues whith >>> merged PRs, which for anyone trying to find an existing jira issue to work >>> on makes it unnecessary difficult to decide whether to look into that or >>> not. From my personal experience, it is somehow frustrating going through >>> open issues, selecting one and after investing some (or even more) time to >>> first understand a problem and then the PR to realise nothing has to be >>> done anymore. Or not knowing what's left out and for what reason. But of >>> course, this is another issue which we definitely need to invest time into >>> - kenn already asked for our support here. >>> >>> thx, >>> >>> michel >>> >>> On Tue, Mar 12, 2019 at 11:30 AM Etienne Chauchot <echauc...@apache.org> >>> wrote: >>> >>>> Hi Thomas, >>>> >>>> I agree, the committer that merges a PR should close the ticket. And, >>>> if needed, he could discuss with the author (inside the PR) to assess if >>>> the PR covers the ticket scope. >>>> >>>> This is the rule I apply to myself when I merge a PR (even thought it >>>> has happened that I forgot to close one or two tickets :) ) . >>>> >>>> Etienne >>>> >>>> >>>> Le lundi 11 mars 2019 à 14:17 -0700, Thomas Weise a écrit : >>>> >>>> JIRA probably deserves a separate discussion. It is messy.. We also >>>> have examples of tickets being referenced by users that were not closed, >>>> although the feature long implemented or issue fixed. >>>> >>>> There is no clear ownership in our workflow. >>>> >>>> A while ago I proposed in another context to make resolving JIRA part >>>> of committer duty. I would like to bring this up for discussion again: >>>> >>>> https://github.com/apache/beam/pull/7129#discussion_r236405202 >>>> >>>> Thomas >>>> >>>> >>>> On Mon, Mar 11, 2019 at 1:47 PM Ahmet Altay <al...@google.com> wrote: >>>> >>>> I agree this is a good idea. I used the same technique for 2.11 blog >>>> post (JIRA release notes -> editorialized list + diffed the dependencies). >>>> >>>> On Mon, Mar 11, 2019 at 1:40 PM Kenneth Knowles <k...@apache.org> >>>> wrote: >>>> >>>> That is a good idea. The blog post is probably the main avenue where >>>> folks will find out about new features or big fixes. >>>> >>>> When I did 2.10.0 I just used the automated Jira release notes and >>>> pulled out significant things based on my judgment. I would also suggest >>>> that our Jira hygiene could be significantly improved to make this process >>>> more effective. >>>> >>>> >>>> +1 to improving JIRA notes as well. Often times issues are closed with >>>> no real comments on what happened, has it been resolved or not. It becomes >>>> an exercise on reading the linked PRs to figure out what happened. >>>> >>>> >>>> >>>> Kenn >>>> >>>> On Mon, Mar 11, 2019 at 1:04 PM Thomas Weise <t...@apache.org> wrote: >>>> >>>> Ahmet, thanks managing the release! >>>> >>>> I have a suggestion (not specific to only this release): >>>> >>>> The release blogs could be more useful to users. In this case, we have >>>> a long list of dependency updates on the top, but probably the improvements >>>> and features section should come first. I was also very surprised to find >>>> "Portable Flink runner support for running cross-language transforms." >>>> mentioned, since that is only being worked on now. On the other hand, there >>>> are probably items that we miss. >>>> >>>> Since this can only be addressed by more eyes, I suggest that going >>>> forward the blog pull request is included and reviewed as part of the >>>> release vote. >>>> >>>> Also, we should make announcing the release on Twitter part of the >>>> process. >>>> >>>> >>>> >>>> This is actually part of the release process ( >>>> https://beam.apache.org/contribute/release-guide/#social-media). I >>>> missed it for 2.11. I will send an announcement on Twitter shortly. >>>> >>>> >>>> >>>> Thanks, >>>> Thomas >>>> >>>> >>>> On Mon, Mar 11, 2019 at 10:46 AM Ahmet Altay <al...@google.com> wrote: >>>> >>>> I updated the JIRAs for these two PRs to set the fix version correctly >>>> as 2.12.0. That should fix the release notes issue. >>>> >>>> On Mon, Mar 11, 2019 at 10:44 AM Ahmet Altay <al...@google.com> wrote: >>>> >>>> Hi Etienne, >>>> >>>> I cut the release branch on 2/14 at [1] (on Feb 14, 2019, 3:52 PM PST >>>> -- github timestamp). Release tag, as you pointed out, points to a commit >>>> on Feb 25, 2019 11:48 PM PST. And that is a commit on the release branch. >>>> >>>> After cutting the release branch, I only merged cherry picks from >>>> master to the release branch if a JIRA was tagged as a release blocker and >>>> there was a PR to fix that specific issue. In case of these two PRs, they >>>> were merged at Feb 20 and Feb 18 respectively. They were not included in >>>> the branch cut and I did not cherry pick them either. I apologize if I >>>> missed a request to cherry pick these PRs. >>>> >>>> Does this answer your question? >>>> >>>> Ahmet >>>> >>>> [1] >>>> https://github.com/apache/beam/commit/a103edafba569b2fd185b79adffd91aaacb790f0 >>>> >>>> On Mon, Mar 11, 2019 at 1:50 AM Etienne Chauchot <echauc...@apache.org> >>>> wrote: >>>> >>>> @Ahmet sorry I did not have time to check 2.11 release but a fellow >>>> Beam contributor drew my attention on something: >>>> >>>> the 2.11 release tag points on commit of 02/26 and this[1] PR was >>>> merged 02/20 and that [2] PR was merged on 02/18. So, both commits should >>>> be in the released code but they are not. >>>> >>>> [1] https://github.com/apache/beam/pull/7348 >>>> [2] https://github.com/apache/beam/pull/7751 >>>> >>>> So at least for those 2 features the release notes do not comply to >>>> content of the release. Is there a real problem or did I miss something ? >>>> >>>> Etienne >>>> >>>> Le lundi 04 mars 2019 à 11:42 -0800, Ahmet Altay a écrit : >>>> >>>> Thank you for the additional votes and validations. >>>> >>>> Update: Binaries are pushed. Website updates are blocked on an issue >>>> that is preventing beam-site changes to be synced the beam website. >>>> (INFRA-17953). I am waiting for that to be resolved before sending an >>>> announcement. >>>> >>>> On Mon, Mar 4, 2019 at 3:00 AM Robert Bradshaw <rober...@google.com> >>>> wrote: >>>> >>>> I see the vote has passed, but +1 (binding) from me as well. >>>> >>>> On Mon, Mar 4, 2019 at 11:51 AM Jean-Baptiste Onofré <j...@nanthrax.net> >>>> wrote: >>>> > >>>> > +1 (binding) >>>> > >>>> > Tested with beam-samples. >>>> > >>>> > Regards >>>> > JB >>>> > >>>> > On 26/02/2019 10:40, Ahmet Altay wrote: >>>> > > Hi everyone, >>>> > > >>>> > > Please review and vote on the release candidate #2 for the version >>>> > > 2.11.0, as follows: >>>> > > >>>> > > [ ] +1, Approve the release >>>> > > [ ] -1, Do not approve the release (please provide specific >>>> comments) >>>> > > >>>> > > The complete staging area is available for your review, which >>>> includes: >>>> > > * JIRA release notes [1], >>>> > > * the official Apache source release to be deployed to >>>> dist.apache.org >>>> > > <http://dist.apache.org> [2], which is signed with the key with >>>> > > fingerprint 64B84A5AD91F9C20F5E9D9A7D62E71416096FA00 [3], >>>> > > * all artifacts to be deployed to the Maven Central Repository [4], >>>> > > * source code tag "v2.11.0-RC2" [5], >>>> > > * website pull request listing the release [6] and publishing the >>>> API >>>> > > reference manual [7]. >>>> > > * Python artifacts are deployed along with the source release to the >>>> > > dist.apache.org <http://dist.apache.org> [2]. >>>> > > * Validation sheet with a tab for 2.11.0 release to help with >>>> validation >>>> > > [8]. >>>> > > >>>> > > The vote will be open for at least 72 hours. It is adopted by >>>> majority >>>> > > approval, with at least 3 PMC affirmative votes. >>>> > > >>>> > > Thanks, >>>> > > Ahmet >>>> > > >>>> > > [1] >>>> > > >>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527&version=12344775 >>>> > > [2] https://dist.apache.org/repos/dist/dev/beam/2.11.0/ >>>> > > [3] https://dist.apache.org/repos/dist/release/beam/KEYS >>>> > > [4] >>>> https://repository.apache.org/content/repositories/orgapachebeam-1064/ >>>> > > [5] https://github.com/apache/beam/tree/v2.11.0-RC2 >>>> > > [6] https://github.com/apache/beam/pull/7924 >>>> > > [7] https://github.com/apache/beam-site/pull/587 >>>> > > [8] >>>> > > >>>> https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=542393513 >>>> > > >>>> > >>>> > -- >>>> > Jean-Baptiste Onofré >>>> > jbono...@apache.org >>>> > http://blog.nanthrax.net >>>> > Talend - http://www.talend.com >>>> >>>>
