What do you mean by “merging cannot happen through the GitHub user interface”? 
You can in fact merge PRs by clicking on the merge button, or “rebase and 
merge”.

Aljoscha

> On 29. Jan 2019, at 11:58, Robert Metzger <rmetz...@apache.org> wrote:
> 
> @Fabian: Thank you for your suggestions. Multiple approvals in one comment
> are already possible.
> I will see if I can easily add multiple approvals in one line as well.
> I will also address 2) and 3).
> 
> Regarding usage of the bot: Anyone can use it! It is up to the committer
> who's merging in the end whether they are happy with the approver.
> One of the feature ideas I have is to indicate whether somebody is PMC or
> committer.
> 
> I'm against enforcing the order of approvals for now. I fear that this will
> make the tool too restrictive. I like Ufuk's idea of putting a note into
> the tracking comment for now.
> Once it's active and we are using it day to day, we'll probably learn what
> features we need the most.
> 
> 
> @Ufuk: I think we should put it into a Apache repo at some point. But I'm
> not sure if it's worth going through the effort of setting up a new repo
> now, given that the bot is not even active yet, and we are not sure if it's
> going to be useful.
> Once it is active for a month or two, I will move it.
> 
> Regarding the bots in general: I don't see a problem with having multiple
> bots in place, as long as they get along with each other well.
> We should try not to reinvent the wheel, if there's already a good bot
> implementation, I don't see a reason to not use it.
> The problem in our case is that we have limited access to our GitHub page,
> and merging can not happen through the GitHub user interface -- so I guess
> many "off the shelf" bots will not work in our environment.
> I'm thinking already about approaches how to automatically merge pull
> requests with the bot. But this will be a separate mailing list thread :)
> 
> Thanks for the feedback!
> 
> 
> 
> 
> On Mon, Jan 28, 2019 at 5:20 PM Ufuk Celebi <u...@apache.org> wrote:
> 
>> Thanks for the clarification. I agree that it only makes sense to
>> check the points in order. +1 to add this if we can think of a nice
>> way to do it. I'm not sure how we would enforce the order with the bot
>> since there is only indirect feedback to a bot command. The only thing
>> I can think of at the moment is to add a note to a check in case
>> earlier steps where not executed. Just ignoring a bot command because
>> other commands have not been executed before feels not helpful to me
>> (since we can't prevent reviewers to jump to later steps if they wish
>> to do so).
>> 
>> I'd rather add a bold note to the bot template that makes clear that
>> all points should be followed in order to avoid potentially redundant
>> work.
>> 
>> – Ufuk
>> 
>> On Mon, Jan 28, 2019 at 5:01 PM Fabian Hueske <fhue...@gmail.com> wrote:
>>> 
>>> The points in the review template are in the order in which they should
>> be
>>> checked, i.e., first checking the description, then consensus and finally
>>> checking the code.
>>> Currently, it is possible to tick off the code box before checking the
>>> description.
>>> One motivation for the process was to do the steps in exactly the
>> proposed
>>> order for example to to avoid detailed code reviews before there was
>>> consensus whether the contribution was welcome or not.
>>> 
>>> Am Mo., 28. Jan. 2019 um 16:54 Uhr schrieb Ufuk Celebi <u...@apache.org>:
>>> 
>>>> I played around with the bot and it works pretty well. :-) @Robert:
>>>> Are there any plans to contribute the code for the bot to Apache
>>>> (potentially in another repository)?
>>>> 
>>>> I like Fabians suggestions. Regarding the questions:
>>>> 1) I would make that dependent on whether you expected the review
>>>> guideline to only apply to committers or also regular contributors.
>>>> Since the bot is not merging PRs, I don't see a down side in having it
>>>> open for all contributors (except potential noise).
>>>> 2) What do you mean with "order of approvals"?
>>>> 
>>>> Since there is another lively discussion going on about a bot for
>>>> stale PRs, I'm wondering what the future plans for @flinkbot are. Do
>>>> we want to have multiple bots for the project? Or do you plan to
>>>> support staleness checks in the future? What about merging of PRs?
>>>> 
>>>> – Ufuk
>>>> 
>>>> On Mon, Jan 28, 2019 at 4:23 PM Fabian Hueske <fhue...@gmail.com>
>> wrote:
>>>>> 
>>>>> Hi Robert,
>>>>> 
>>>>> Thanks for working on the bot!
>>>>> I have a few suggestions / questions:
>>>>> 
>>>>> Suggestions:
>>>>> 1) It would be great to approve multiple boxes in one comment.
>> Either as
>>>>>> @flinkbot approve contribution consensus
>>>>> or by
>>>>>> @flinkbot approve contribution
>>>>>> @flinkbot approve consensus
>>>>> 
>>>>> 2) Extend the last line of the description by adding something like
>> "See
>>>>> Pull Request Review Guide for how to use the Flink bot."?
>>>>> 3) Rephrase the first line to include "[description]" instead of
>>>>> "[contribution]", as it is about approving the description
>>>>> 
>>>>> Questions:
>>>>> 1) Can anybody use the bot or just committers?
>>>>> 2) Does it make sense to enforce the order in which approvals are
>> given?
>>>>> 
>>>>> Best,
>>>>> Fabian
>>>>> 
>>>>> Am Mi., 23. Jan. 2019 um 13:51 Uhr schrieb Robert Metzger <
>>>>> rmetz...@apache.org>:
>>>>> 
>>>>>> I have the bot now running in
>>>> https://github.com/flinkbot/test-repo/pulls
>>>>>> Feel free to play with it.
>>>>>> 
>>>>>> On Wed, Jan 23, 2019 at 10:25 AM Robert Metzger <
>> rmetz...@apache.org>
>>>>>> wrote:
>>>>>> 
>>>>>>> Okay, cool! I'll let you know when the bot is ready in a test
>> repo.
>>>>>>> While you (and others) are testing it, I'll open a PR for the
>> docs.
>>>>>>> 
>>>>>>> On Wed, Jan 23, 2019 at 10:15 AM Fabian Hueske <
>> fhue...@gmail.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Oh, that's great news!
>>>>>>>> In that case we can just close the PR and start with the bot
>> right
>>>> away.
>>>>>>>> I think it would be good to extend the PR Review guide [1] with
>> a
>>>>>> section
>>>>>>>> about the bot and how to use it.
>>>>>>>> 
>>>>>>>> Fabian
>>>>>>>> 
>>>>>>>> [1] https://flink.apache.org/reviewing-prs.html
>>>>>>>> 
>>>>>>>> Am Mi., 23. Jan. 2019 um 10:03 Uhr schrieb Robert Metzger <
>>>>>>>> rmetz...@apache.org>:
>>>>>>>> 
>>>>>>>>> Hey,
>>>>>>>>> 
>>>>>>>>> as I've mentioned already in the pull request, I have started
>>>>>>>> implementing
>>>>>>>>> a little bot for GitHub that tracks the checklist [1]
>>>>>>>>> The bot is monitoring incoming pull requests. It creates a
>> comment
>>>>>> with
>>>>>>>> the
>>>>>>>>> checklist.
>>>>>>>>> Reviewers can write a message to the bot (such as "@flinkbot
>>>> approve
>>>>>>>>> contribution"), then the bot will update the checklist
>> comment.
>>>>>>>>> 
>>>>>>>>> As an upcoming feature, I also plan to add a label to the pull
>>>> request
>>>>>>>> when
>>>>>>>>> all the checklist conditions have been met.
>>>>>>>>> 
>>>>>>>>> I hope to finish the bot today. After some initial testing,
>> we can
>>>>>>>> deploy
>>>>>>>>> it with Flink (if there are no objections by the community).
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> [1] https://github.com/rmetzger/flink-community-tools
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Tue, Jan 22, 2019 at 3:48 PM Fabian Hueske <
>> fhue...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Hi everyone,
>>>>>>>>>> 
>>>>>>>>>> A few months ago the community discussed and agreed to
>> improve
>>>> the
>>>>>> PR
>>>>>>>>>> review process [1-4].
>>>>>>>>>> The idea is to follow a checklist to avoid in-depth reviews
>> on
>>>>>>>>>> contributions that might not be accepted for other reasons.
>>>> Thereby,
>>>>>>>>>> reviewers and contributors do not spend their time on PRs
>> that
>>>> will
>>>>>>>> not
>>>>>>>>> be
>>>>>>>>>> merged.
>>>>>>>>>> The checklist consists of five points:
>>>>>>>>>> 
>>>>>>>>>> 1. The contribution is well-described.
>>>>>>>>>> 2. There is consensus that the contribution should go into
>> to
>>>> Flink.
>>>>>>>>>> 3. [Does not need specific attention | Needs specific
>> attention
>>>> for
>>>>>> X
>>>>>>>> |
>>>>>>>>> Has
>>>>>>>>>> attention for X by Y]
>>>>>>>>>> 4. The architectural approach is sound.
>>>>>>>>>> 5. Overall code quality is good.
>>>>>>>>>> 
>>>>>>>>>> Back then we added a review guide to the website [5] but did
>>>> not put
>>>>>>>> the
>>>>>>>>>> new process in place yet. I would like to start this now.
>>>>>>>>>> There is a PR [6] that adds the review checklist to the PR
>>>> template.
>>>>>>>>>> Committers who review add PR should follow the checklist and
>>>> tick
>>>>>> and
>>>>>>>>> sign
>>>>>>>>>> off the boxes by updating the PR description. For that
>>>> committers
>>>>>>>> need to
>>>>>>>>>> be members of the ASF Github organization.
>>>>>>>>>> 
>>>>>>>>>> If nobody has concerns, I'll merge the PR in a few days.
>>>>>>>>>> Once the PR is merged, the reviews of all new PRs should
>> follow
>>>> the
>>>>>>>>>> checklist.
>>>>>>>>>> 
>>>>>>>>>> Best,
>>>>>>>>>> Fabian
>>>>>>>>>> 
>>>>>>>>>> [1]
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> https://lists.apache.org/thread.html/dcbe377eb477b531f49c462e90d8b1e50e0ff33c6efd296081c6934d@%3Cdev.flink.apache.org%3E
>>>>>>>>>> [2]
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> https://lists.apache.org/thread.html/172aa6d12ed442ea4da9ed2a72fe0894c9be7408fb2e1b7b50dfcb8c@%3Cdev.flink.apache.org%3E
>>>>>>>>>> [3]
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> https://lists.apache.org/thread.html/5e07c1be8078dd7b89d93c67b71defacff137f3df56ccf4adb04b4d7@%3Cdev.flink.apache.org%3E
>>>>>>>>>> [4]
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> https://lists.apache.org/thread.html/d7fd1fe45949f7c706142c62de85d246c7f6a1485a186fd3e9dced01@%3Cdev.flink.apache.org%3E
>>>>>>>>>> [5] https://flink.apache.org/reviewing-prs.html
>>>>>>>>>> [6] https://github.com/apache/flink/pull/6873
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 

Reply via email to