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

Reply via email to