+1 for the committer to close the PR upon merge. I think it is better to
risk closing it prematurely and having it reopened than not closing it
at all.
Also if in doubt, committers just leave a comment in the JIRA asking the
reporter if it can be closed.
-Max
On 14.03.19 23:42, Reuven Lax wrote:
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
<mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
<mailto: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 <mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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>
> > <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>
<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
<mailto:jbono...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
