IMHO, I think the "rule of thumb” should be to accept a PR which was done by correspondent Jira's assigner (of course if it correctly addresses and fixes initial issue). Jira assigning should be like a “mutex” (as Kenn said in other discussion) for a person who works on this. Though, we need to unassign long-taken issues if there is no progress and it would allow other people take this task and work on this without any conflicts after.
In mean time, we need to check for Jira duplicates to prevent the situations described above and, if any, the first created Jira should “win” in case of conflicts. By “we” here I mean Beam devs who are responsible for concrete component and manage regularly its tasks.. > On 28 Nov 2019, at 11:32, Etienne Chauchot <echauc...@apache.org> wrote: > > Hi all, > > FYI, I closed the most recent one (with explanation and a sorry message): > > https://github.com/apache/beam/pull/10025 > > Etienne > > On 26/11/2019 17:06, Robert Bradshaw wrote: >> On Tue, Nov 26, 2019 at 6:15 AM Etienne Chauchot <echauc...@apache.org> >> wrote: >>> Hi guys, >>> >>> I wanted your opinion about something: >>> >>> I have 2 concurrent PRs that do the same: >>> >>> https://github.com/apache/beam/pull/10010 >>> >>> https://github.com/apache/beam/pull/10025 >>> >>> The first one is a bit better because it addresses a deprecation that >>> the other does not address. Except that they are the same. The first one >>> the the older (1 day before) but the second one is the one that received >>> reviews. >>> >>> I guess the problem is that there were 3 duplicate tickets of >>> Elasticsearch7 upgrade (because people do not search for existing >>> tickets before opening). As a result concurrent PRs were submitted >>> despite the PR link on jira. I removed the duplicates but I need to >>> close one of the PRs. >>> >>> The question is: which one do you think should be closed? >> Are there (summary) pros and cons of the various pros and cons that >> you're looking for feedback on? Otherwise, I think you could make the >> call. (It's a good reminder of trying to search for issues on JIRA >> before filing a new one though.)
