I have in the past created JIRAs that took several PRs to close. Often this happened when I decided that a PR was too large and split it up into several smaller PRs.
On Thu, Mar 14, 2019 at 12:09 PM Thomas Weise <t...@apache.org> wrote: > I see many other projects where JIRAs are resolved when the PR is merged. > It is simple and seems to work well. > > As a reviewer that merges a PR, I need to have an understanding of the > scope of the work. I cannot remember an instance where it wasn't clear to > me if a JIRA should be resolved or not. Do others have examples? > > It is important that JIRAs are resolved and fields like component, issue > type and fix version are properly set for the releases. IMO the committer > is in the best position to verify that. > > The contributor usually isn't incentivised to massage a JIRA ticket after > the code was merged. That is probably the main reason why we find ourselves > with many dangling tickets. Merge is usually the last action in the > workflow, at which point we also know what the fix version is. > > Thomas > > > > > > On Thu, Mar 14, 2019 at 11:58 AM Mikhail Gryzykhin <mig...@google.com> > wrote: > >> 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 >>>>>> >>>>>>
