Oh I agree with this. I'm just saying that an automated close on merge might not always do the right thing.
On Mon, Mar 18, 2019 at 4:51 AM Etienne Chauchot <echauc...@apache.org> wrote: > Well, I agree but a contributor might not have the rights on jira and more > important he might be unable to chose a target version for the jira. > Targeting the ticket to the correct version requires to know the release > cut date which is not the date of the commit to which the release tag > points in case of cherry picks. It seems a bit complicated for a one-time > contributor. This is why I proposed that the committer/reviewer does the > jira closing. > > Etienne > > > Le mercredi 13 mars 2019 à 17:08 -0700, Ahmet Altay a écrit : > > 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 > >