+1
Best,
Shengjk1
On 03/23/2019 12:08，vino yang wrote：
+1
Best,
Vino
Bowen Li 于2019年3月23日周六 上午12:28写道：
+1, sounds good, Jark.
On Fri, Mar 22, 2019 at 1:55 AM Fabian Hueske wrote:
Hi Jark,
Thanks for driving the effort to integrate the Chinese website!
We have the policy that new feat
+1
Best,
Vino
Bowen Li 于2019年3月23日周六 上午12:28写道：
> +1, sounds good, Jark.
>
> On Fri, Mar 22, 2019 at 1:55 AM Fabian Hueske wrote:
>
> > Hi Jark,
> >
> > Thanks for driving the effort to integrate the Chinese website!
> >
> > We have the policy that new features / improvements should be documen
+1, sounds good, Jark.
On Fri, Mar 22, 2019 at 1:55 AM Fabian Hueske wrote:
> Hi Jark,
>
> Thanks for driving the effort to integrate the Chinese website!
>
> We have the policy that new features / improvements should be documented in
> the same PR for a long time.
> So far, this was checked by
Hi Jark,
Thanks for driving the effort to integrate the Chinese website!
We have the policy that new features / improvements should be documented in
the same PR for a long time.
So far, this was checked by reviewers and committers but often overlooked
or decided to add documentation in a subseque
Hi all,
In the past discussion of Supporting Chinese Documentation for Apache
Flink[1], we reach a consensus to add a documentation check item to the
flinkbot review process.
I propose the idea here to get some more feedbacks about this.
The new item we want to add is:
```
### 6. Are English an
Each Jira ticket has a "last updated" field, and in a JIRA search, you can
sort results by that field.
So I will regularly check all Jira tickets which have been updated since
the last time my tool checked. For all changed Jira tickets, I'll update
the PR if the component has changed.
The impleme
How do you intend to keep the label up-to-date with whatever
modifications are made in JIRA?
On 07.03.2019 13:40, Robert Metzger wrote:
I will automatically assign the Jira component as a label to the PR, yes.
You won't have to manually update the label on the PR, this will be done
automaticall
I will automatically assign the Jira component as a label to the PR, yes.
You won't have to manually update the label on the PR, this will be done
automatically.
So JIRA will stay the ground truth for setting the component correctly.
On Thu, Mar 7, 2019 at 10:11 AM Chesnay Schepler wrote:
> Com
Component labels seem a bit redundant. Every JIRA with an open PR
already has a "pull-request-available" tag.
So this information already exists.
I assume you'll base the labels on the component tags at the time the PR
is opened, but this also implies that they may be set incorrectly (or
not a
This is the picture:
https://user-images.githubusercontent.com/89049/53882383-7fda9380-4016-11e9-877d-10cdc00bdfbd.png
Speaking about feature requests, priorities and time-spend: My plan was to
now work on introducing a new label category for the components.
This should get us a lot better overvie
The image didn't go through.
I would keep it as is; imo there are significantly more important things
that I'd like Robert to spend time on. (literally everything in the
Feature requests section)
If we want to better distinguish new PRs I would suggest to either a)
introduce a dedicated "New
Hey Kurt,
thanks a lot for this idea.
My reasoning behind using just one color is the following: I wanted to use
one color per category of labels.
So when we are introducing labels for components, that it'll look like this:
[image: image.png]
But we could of course also go with color families pe
Hi Dev,
I've been using the flinkbot and the label for a couple days, it worked
really well! I have a minor suggestion, can we
use different colors for different labels? We don't need to have different
colors for every label, but only to distinguish whether
someone had review the PR.
For example,
GitHub has two methods for authentication with the APIs:
a) using an account's oauth token
b) using the GitHub Apps API
Most of the libraries for the GH API use a), so does Flinkbot. The problem
with a) is that it does not allow for fine-grained access control, and
Infra does not want to give Flin
It would be good to encourage participation of non-committers in the review
process, so +1 for allowing everyone to operate the bot.
Github approval will show a green checkmark for committer approval
(assuming accounts were linked via gitbox) - that should provide sufficient
orientation?
I just n
I will update labels only based on committer's approvals (for everything),
I think that's cleaner.
We can always revisit this.
On Wed, Feb 27, 2019 at 4:31 PM Chesnay Schepler wrote:
> Fore code-quality/description I agree, but consensus and the final
> approval should require a committer IMO.
Fore code-quality/description I agree, but consensus and the final
approval should require a committer IMO.
On 27.02.2019 15:08, Robert Metzger wrote:
I did not put any restrictions on who can communicate with the bot!
But since there is currently no way of overriding somebody's approval
for s
I did not put any restrictions on who can communicate with the bot!
But since there is currently no way of overriding somebody's approval for
something, this can easily lead to such a situation.
My thinking was that a committer still needs to manually check who approved
a pull request, and I wante
Just noticed that _anyone_ can approve a PR now, see
https://github.com/apache/flink/pull/7801.
Not sure about the solution, but as it stands it is rather trivial to
nuke the review process of the entire project.
On 13.02.2019 10:29, Robert Metzger wrote:
Hey all,
the flinkbot has been acti
Ah, I didn't get that. I thought you only wanted to show ❓ instead of ❌.
Maybe the "disapprove" command is also a bit misleading. What it actually
means is just "remove approval".
On Fri, Feb 22, 2019 at 2:29 PM Chesnay Schepler wrote:
> 3 states for each step is effectively what I've been sug
3 states for each step is effectively what I've been suggesting at the
very start. (initialize with question mark instead of red cross)
On 22.02.2019 14:19, Robert Metzger wrote:
I will try to deploy the first version using labels today.
Here are my responses to your comments:
The emojis
Wasn't Chesnay's comment suggesting 3 states as well?:
> 1) By default the bot shows a big red X next to every item; I'd prefer a
> question mark here as this allows us to differentiate between rejected
> and unaddressed points. It's also a bit nicer for contributors imo as it
> does not have such
I will try to deploy the first version using labels today.
Here are my responses to your comments:
The emojis seem unnecessary, the approved label could be shorted to
> "Approved"; the
> review prefix isn't necessary here imo.
My idea was that each system (review bot, component labeler, size
es
The bot could check the diff and tag pull requests that only touch the
docs as "Documentation". Many of these are easy to review and usually
don't require a deeper understanding of Flink.
On 13.02.2019 10:29, Robert Metzger wrote:
Hey all,
the flinkbot has been active for a week now, and I ho
Probably I am bit late to the party, but I just started using the Flinkbot.
A big +1 for having 3 states for each step. (Pending, Approved,
Rejected). Right now it is impossible to say
that I checked e.g. consensus and decided that the feature requires
further discussion.
Best,
Dawid
On 21/02
Hi @Robert Metzger the colors of the emojis is not
very important. I think is enough if we can express the intentions clear.
+1 for alternative2, but for the corresponding pictures, if need I can look
for visual design classmates to help. what do you think?
Best,
Jincheng
Robert Metzger 于2019年
I also prefer alternative 2. Instead of using an emoji ( ❓) , can we just
use the "?" character ? For example:
review=description?
IMO, this will be more clear that the description has not been approved
than "review=description".
Thanks,
Jark
On Wed, 20 Feb 2019 at 22:15, Chesnay Schepler wr
I prefer alternative 2 as the first is rather ambiguous. The emojis seem
unnecessary, the approved label could be shorted to "Approved"; the
review prefix isn't necessary here imo.
I would stick the green checkmarks as this is consistent with Travis.
As another request, we may want to ignore f
Thank you all for the proposals!
I've implemented most of the suggestions already, I hope to deploy it soon
to the repo
For the long label names:
I agree with Stephan that they are pretty long at the moment.
*Alternative 1:*
review=
review=☐☐☐☑
review=☐☐☑☑
review=☐☑☑☑
review=✅
*Alternative
The bot could check that the PR title to starts with [FLINK-X] or [hotfix].
On 13.02.2019 10:29, Robert Metzger wrote:
Hey all,
the flinkbot has been active for a week now, and I hope the initial hiccups
have been resolved :)
I wanted to start this as a permanent thread to discuss problems and
I'd like to specify that a PR does not need special attention. Atm you need
to specify a person for point 3.
Big +1 for having a command to approve everything until (and also
including) a specified state.
Cheers,
Till
On Wed, Feb 13, 2019 at 11:17 AM jincheng sun
wrote:
> Hi Robert, Thanks for
Hi Robert, Thanks for bring up the discussion! I think add the labels is
good idea!
About the state of labels, I suggest that the state initializes the red X
turns yellow question mark , and turns blue checkmark when approved.
This way the contributors can know if these tags have been processed.
+1 for question mark instead of X - definitely comes across nicer
Maybe we can we make these labels shorter / more compact?
Do ne need to go through all steps individually, or can one immediately
jump to "approved" with one command? Or jump to "code quality review"?
On Wed, Feb 13, 2019 at 10:41
"More senior members of the community can focus on approving consensus
and architecture of pull requests, while newer members of the community
can focus on “just” reviewing the code quality."
TBH I reallydon't see this happening, so I'm not too hot for this change.
How have you solved the perm
As of right now I'd like 2 things:
1) By default the bot shows a big red X next to every item; I'd prefer a
question mark here as this allows us to differentiate between rejected
and unaddressed points. It's also a bit nicer for contributors imo as it
does not have such a negative connotation.
The first improvement to Flink Bot I would like to introduce is the use of
labels.
I’m proposing to apply one of the following labels depending on the review
progress:
review=needsDescriptionApproval ❌
review=needsConsensusApproval ❌
review=needsArchitectureApproval ❌
review=needsQualityAppro
36 matches
Mail list logo
