Here are my notes from the last DSv2 sync. Sorry it's a bit late!
*Attendees*:
Ryan Blue
John Zhuge
Raynmond McCollum
Terry Kim
Gengliang Wang
Jose Torres
Wenchen Fan
Priyanka Gomatam
Matt Cheah
Russel Spitzer
Burak Yavuz
*Topics*:
- Check in on blockers
- Remove SaveMode
- Reorg
Hey everyone,
I have been working on coming up with a proposal for supporting stage level
resource configuration and scheduling. The basic idea is to allow the user to
specify executor and task resource requirements for each stage to allow the
user to control the resources required at a finer g
On Tue, Aug 6, 2019 at 11:45 AM Myrle Krantz wrote:
> I had understood your position to be that you would be willing to make at
> least some non-coding contributors to committers but that your "line" is
> somewhat different than my own. My response to you assumed that position on
> your part.
On Tue, Aug 6, 2019 at 6:11 PM Sean Owen wrote:
> On Tue, Aug 6, 2019 at 10:46 AM Myrle Krantz wrote:
> >> You can tell there's a range of opinions here. I'm probably less
> >> 'conservative' about adding committers than most on the PMC, right or
> >> wrong, but more conservative than some at th
On Tue, Aug 6, 2019 at 10:46 AM Myrle Krantz wrote:
>> You can tell there's a range of opinions here. I'm probably less
>> 'conservative' about adding committers than most on the PMC, right or
>> wrong, but more conservative than some at the ASF. I think there's
>> room to inch towards the middle
> I wonder which project nominees non-coding only committers but I at least
know multiple projects. They all have that serious problem then.
I mean It know multiple projects don't do that and according to what you
said, they all have that serious problem.
2019년 8월 7일 (수) 오전 1:05, Hyukjin Kwon 님이
Well, actually I am rather less conservative on adding committers. There
are multiple people who are active in both non-coding and coding activities.
I as an example am one of Korean meetup admin and my main focus was to
management JIRA. In addition, review the PRs that are not being reviewed.
As I
So I’d like to add non-coding committers, I think there is great value in
both recognizing them and eventually having a broader PMC (eg maybe someone
who’s put a lot of time into teaching Spark has important things to say
about a proposed release, perhaps important enough for a binding vote).
That
On Tue, Aug 6, 2019 at 5:36 PM Sean Owen wrote:
> You can tell there's a range of opinions here. I'm probably less
> 'conservative' about adding committers than most on the PMC, right or
> wrong, but more conservative than some at the ASF. I think there's
> room to inch towards the middle ground
On Tue, Aug 6, 2019 at 1:14 AM Myrle Krantz wrote:
> If someone makes a commit who you are not expecting to make a commit, or in
> an area you weren't expecting changes in, you'll notice that, right?
Not counterarguments, but just more color on the hesitation:
- Probably, but it's less obvious
Severity: Important
Vendor: The Apache Software Foundation
Versions affected:
All Spark 1.x, Spark 2.0.x, Spark 2.1.x, and 2.2.x versions
Spark 2.3.0 to 2.3.2
Description:
Prior to Spark 2.3.3, in certain situations Spark would write user data to
local disk unencrypted, even if spark.io.encryp
My 2 cents as just one of contributors of Apache Spark project.
The thing is, what's the merit for both contributors and PMC members on
granting committership on non-code contributors. I'd rather say someone is
a good candidate to be invited as a committer to co-maintain a part of code
repository
I usually make such judgement about commit bit based upon community
activity in coding and reviewing.
If somebody has no activity about those commit bits, I would have no way to
know about this guy,
Simply I can't make a judgement about coding activity based upon non-coding
activity.
Those bugs an
Hey Hyukjin,
Apologies for sending this to you twice. : o)
On Tue, Aug 6, 2019 at 9:55 AM Hyukjin Kwon wrote:
> Myrle,
>
> > We need to balance two sets of risks here. But in the case of access to
> our software artifacts, the risk is very small, and already has *multiple*
> mitigating factor
So, here's my thought:
1. Back to the original point, for recognition of such people, I think we
can simply list up such people in Spark Website somewhere. For instance,
Person A: Spark Book
Person B: Meetup leader
I don't know if ASF allows this. Someone needs to check it.
2. If we need t
Myrle,
> We need to balance two sets of risks here. But in the case of access to
our software artifacts, the risk is very small, and already has *multiple*
mitigating factors, from the fact that all changes are tracked to an
individual, to the fact that there are notifications sent when changes a
16 matches
Mail list logo
