There are many reasons for jira, and one of the most important reasons is
that flink varies greatly from version to version. However, I agree that
you restrict some rights of developers, including the right to assign and
edit.
Robert Metzger 于2019年7月19日周五 下午10:58写道：
> Hi all!
>
> Chesnay wrote:
Hi all!
Chesnay wrote:
> We haven't wiped the set of contributors yet. Not sure if there's an
> easy way to remove the permissions for all of them; someone from the PMC
> may have to bite the bullet and click 600 times in a row :)
I don't think there's an easy way for us.
People with
Fair enough, we might rephrase as
"Pull requests belonging to unassigned Jira tickets or not authored by
assignee will ..."
For the action "what should we do", iirc someone in this thread proposed
closing it via flinkbot. Or leaving without review and merge could be ok
before we implement
@Jack
>From https://flink.apache.org/contributing/contribute-code.html the
community
claims
- Only start working on the implementation if there is consensus on the
approach (e.g. you are assigned to the ticket)
and accurately answer your question,
- Pull requests belonging to unassigned Jira
A quick question, what should we do if a developer creates a JIRA issue and
then create a pull request at once without assigning?
Regards,
Jark
On Thu, 18 Jul 2019 at 18:50, Zili Chen wrote:
> Checking the result, as a discovery, I found that one can
> still file a JIRA with "blocker"
Checking the result, as a discovery, I found that one can
still file a JIRA with "blocker" priority.
IIRC someone in this thread once mentioned that
"Don't allow contributors to set a blocker priority."
Chesnay,
Thanks for the clarification.
Best,
tison.
Chesnay Schepler 于2019年7月18日周四
We haven't wiped the set of contributors yet. Not sure if there's an
easy way to remove the permissions for all of them; someone from the PMC
may have to bite the bullet and click 600 times in a row :)
On 18/07/2019 12:32, Zili Chen wrote:
Robert,
Thanks for your effort. Rejecting
Robert,
Thanks for your effort. Rejecting contributor permission request
with a nice message and pointing them to the announcement sounds
reasonable. Just to be clear, we now have no person with contributor
role, right?
Chesnay,
https://flink.apache.org/contributing/contribute-code.html has
Do our contribution guidelines contain anything that should be updated?
On 18/07/2019 12:24, Chesnay Schepler wrote:
Sounds good to me.
On 18/07/2019 12:07, Robert Metzger wrote:
Infra has finally changed the permissions. I just announced the
change in a
separate email [1].
One thing I
Sounds good to me.
On 18/07/2019 12:07, Robert Metzger wrote:
Infra has finally changed the permissions. I just announced the change in a
separate email [1].
One thing I wanted to discuss here is, how do we want to handle all the
"contributor permissions" requests?
My proposal is to basically
Infra has finally changed the permissions. I just announced the change in a
separate email [1].
One thing I wanted to discuss here is, how do we want to handle all the
"contributor permissions" requests?
My proposal is to basically reject them with a nice message, pointing them
to my
This is the Jira ticket I opened
https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :)
On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler wrote:
> @Robert what's the state here?
>
> On 24/06/2019 16:16, Robert Metzger wrote:
> > Hey all,
> >
> > I would like to drive this
@Robert what's the state here?
On 24/06/2019 16:16, Robert Metzger wrote:
Hey all,
I would like to drive this discussion to an end soon.
I've just merged the updated contribution guide to the Flink website:
https://flink.apache.org/contributing/contribute-code.html
I will now ask Apache
Hey all,
I would like to drive this discussion to an end soon.
I've just merged the updated contribution guide to the Flink website:
https://flink.apache.org/contributing/contribute-code.html
I will now ask Apache IINFRA to change the permissions in our Jira.
Here's the updated TODO list:
1. I
Hey,
I started working on step 1 and proposed some changes to the Flink website:
https://github.com/apache/flink-web/pull/217
On Tue, Apr 30, 2019 at 4:08 PM Robert Metzger wrote:
> Hi Fabian,
> You are right, I made a mistake. I don't think it makes sense to introduce
> a new permission
Hi Fabian,
You are right, I made a mistake. I don't think it makes sense to introduce
a new permission class. This will make the life of JIRA admins
unnecessarily complicated.
I updated the task list:
1. I update the contribution guide
2. Update Flinkbot to close invalid PRs, and show warnings on
Hi Robert,
If I understood the decision correctly, we also need to ask Infra to make
everybody an assignable user, right?
Or do we want to add a new permission class "Assignable User" such that
everyone still needs to ask for the right Jira permissions?
Fabian
Am Di., 30. Apr. 2019 um 10:46
Hi Robert,
thanks for taking care of this. +1 to your suggested steps.
Regards,
Timo
Am 30.04.19 um 10:42 schrieb Robert Metzger:
@Stephan: I agree. Auto-closing PRs is quite aggressive.
I will only do that for PRs without JIRA ID or "[hotfix]" in the title.
We can always revisit this at a
@Stephan: I agree. Auto-closing PRs is quite aggressive.
I will only do that for PRs without JIRA ID or "[hotfix]" in the title.
We can always revisit this at a later stage.
I'm proposing the following steps:
1. I update the contribution guide
2. Update Flinkbot to close invalid PRs, and show
also +1 for option 2.
I think auto-close a PR sometimes a bit impertinency.
The reasons just like Stephan mentioned.
Stephan Ewen 于2019年4月24日周三 下午4:08写道：
> About auto-closing PRs from unassigned issues, consider the following case
> that has happened quite a bit.
>
> - a user reports a small
About auto-closing PRs from unassigned issues, consider the following case
that has happened quite a bit.
- a user reports a small bug and immediately wants to provide a fix for it
- it makes sense to not stall the user for a few days until a committer
assigned the issue
- not auto-closing
I think this really depends on the contribution.
Sometimes "triviality" means that people just want to fix a typo in some
docs. For this, a hotfix PR is sufficient and does not need a JIRA issue.
However, sometimes "triviality" is only trivial at first glance but
introduces side effects. In
Hi everyone,
just my two cents: as a non-committer I appreciate a lightweight,
frictionless process for trivial changes or small fixes without the need to
approach a committer beforehand. If it takes 5 days, so that I can start
with a triviality, I might not bother in the first place. So, in
@Robert thanks for pointing out and sorry for confusion. The correct text:
+1 for option 1.
I also do not mind option 2, after 1-2 contributions, any contributor could
just ask the committer (who merged those contributions) about contributor
permissions.
Best,
Andrey
On Mon, Apr 15, 2019 at
Hello there,
New to the community. Just thought you might want some inputs from new
comers too.
I prefer option 2, where you need to prove the ability and commitment with
commits before contributor permission is assigned.
Cheers,
Feng
Le lun. 15 avr. 2019 à 09:17, Robert Metzger a écrit :
>
@Andrey: You mention "option 2" two times, I guess one of the two uses of
"option 2" contains a typo?
On Wed, Apr 10, 2019 at 10:33 AM Andrey Zagrebin
wrote:
> Hi all,
>
> +1 for option 2.
>
> I also do not mind option 2, after 1-2 contributions, any contributor could
> just ask the committer
Hi all,
+1 for option 2.
I also do not mind option 2, after 1-2 contributions, any contributor could
just ask the committer (who merged those contributions) about contributor
permissions.
Best,
Andrey
On Wed, Apr 10, 2019 at 3:58 AM Robert Metzger wrote:
> I'm +1 on option 1.
>
> On Tue, Apr
I'm +1 on option 1.
On Tue, Apr 9, 2019 at 1:58 AM Timo Walther wrote:
> Hi everyone,
>
> I'd like to bring up this discussion thread again. In summary, I think
> we all agreed on improving the JIRA workflow to move design/consensus
> discussions from PRs to the issues first, before
Hi everyone,
I'd like to bring up this discussion thread again. In summary, I think
we all agreed on improving the JIRA workflow to move design/consensus
discussions from PRs to the issues first, before implementing them.
Two options have been proposed:
1. Only committers can assign people
@Fabian: I don't think this is a big problem. Moving away from "giving
everybody contributor permissions" to "giving it to some people" is not
risky.
I would leave this decision to the committers who are working with a person.
We should bring this discussion to a conclusion and implement the
Hi,
I'm not sure about adding an additional stage.
Who's going to decide when to "promote" a user to a contributor, i.e.,
grant assigning permission?
Best, Fabian
Am Do., 14. März 2019 um 13:50 Uhr schrieb Timo Walther :
> Hi Robert,
>
> I also like the idea of making every Jira user an
Hi Robert,
I also like the idea of making every Jira user an "Assignable User", but
restrict assigning a ticket to people with committer permissions.
Instead of giving contributor permissions to everyone, we could have a
more staged approach from user, to contributor, and finally to
Hi Tison,
I also thought about this.
Making a person a "Contributor" is required for being an "Assignable User",
so normal Jira accounts can't be assigned to a ticket.
We could make every Jira user an "Assignable User", but restrict assigning
a ticket to people with committer permissions.
There
Hi devs,
Just now I find that one not a contributor can file issue and participant
discussion.
One becomes contributor can additionally assign an issue to a person and
modify fields of any issues.
For a more restrictive JIRA workflow, maybe we achieve it by making it a
bit more
restrictive
I like this idea and I would like to try it to see if it solves the problem.
I can also offer to add a functionality to the Flinkbot to automatically
close pull requests which have been opened against a unassigned JIRA ticket.
Being rejected by an automated system, which just applies a rule is
@Chesnay - yes, this is possible, according to infra.
On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen wrote:
> Hi,
>
> @Hequn
> It might be hard to separate JIRAs into conditional and unconditional ones.
>
> Even if INFRA supports such separation, we meet the problem that whether
> a contributor is
Hi,
@Hequn
It might be hard to separate JIRAs into conditional and unconditional ones.
Even if INFRA supports such separation, we meet the problem that whether
a contributor is granted to decide the type of a JIRA. If so, then
contributors might
tend to create JIRAs as unconditional; and if not,
We currently cannot change the JIRA permissions. Have you asked INFRA
whether it is possible to setup a Flink-specific permission scheme?
On 25.02.2019 14:23, Timo Walther wrote:
Hi everyone,
as some of you might have noticed during the last weeks, the Flink
community grew quite a bit. A lot
Hi, Timo
Thanks for putting this together and bring the discussion. +1 to making our
JIRAs a bit more restrictive!
I think this makes a good point of view. It would be helpful to force the
contributors to think more about the issues rather than take it directly or
maybe rashly.
One little
I like the idea of pushing more for "discuss before opening a PR", and this
could help with that part.
We have to be clear though that this is not meant as a way to discourage
contributions.
If we decide to switch to that mode, I think we need to
- Concurrently update the contribution guide and
Hi,
I think this is very valuable discussion and thank you for starting it.
In general I am +1 for this proposal. I think though we must make it
very clear that this will require a careful handling by committers.
There are at least two cases that come to my mind that we need to be
aware of:
*
Really nice idea Timo,
Thanks for taking the initiative to open this discussion.
Although a side-effect, I consider it a big argument about my +1
the fact that now we create backpressure whenever needed at the
JIRA level, rather than at the open PR level.
The reason is that not accepting a PR
Hi everyone,
as some of you might have noticed during the last weeks, the Flink
community grew quite a bit. A lot of people have applied for contributor
permissions and started working on issues, which is great for the growth
of Flink!
However, we've also observed that managing JIRA and
43 matches
Mail list logo
