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 >> >>
