This vote passes with only +1s. In conjunction with the discussion I
believe we have consensus. I will update the website this week with the
proposed change. Thank you all for your participation.
On Sun, Aug 2, 2020 at 9:33 PM Prashant Sharma wrote:
> +1
>
> On Fri, Jul 31, 2020 at 10:18 PM
Oh I think I caused some confusion here.
Just for clarification, I wasn’t saying we must port this into a separate
repo now. I was saying it can be one of the options we can consider.
For a bit of more context:
This option was considered as, roughly speaking, an invalid option and it
might need
Hi all,
I am going to prepare the realease of 3.0.1 RC1, with the help of Wenchen.
-- 原始邮件 --
发件人:
"Jason Moore"
Indeed, though the possible advantage is that in theory, you can have
different release cycle than for the main repo (I am not sure if that's
feasible in practice or if that was the intention).
I guess all depends on how we envision the future of annotations
(including, but not limited to, how
So IMO maintaining outside in a separate repo is going to be harder. That was
why I asked.
From: Maciej Szymkiewicz
Sent: Tuesday, August 4, 2020 12:59 PM
To: Sean Owen
Cc: Felix Cheung; Hyukjin Kwon; Driesprong, Fokko; Holden Karau; Spark Dev List
Subject:
On 8/4/20 9:35 PM, Sean Owen wrote
> Yes, but the general argument you make here is: if you tie this
> project to the main project, it will _have_ to be maintained by
> everyone. That's good, but also exactly I think the downside we want
> to avoid at this stage (I thought?) I understand for some
On Tue, Aug 4, 2020 at 2:32 PM Maciej Szymkiewicz
wrote:
>
> First of all why ASF ownership?
>
> For the project of this size maintaining high quality (it is not hard to use
> stubgen or monkeytype, but resulting annotations are rather simplistic)
> annotations independent of the actual
I think that's fine to resolve as you did. I would recommend answering
on sites like StackOverflow rather than the JIRA. That said, because
the answer is pretty trivial to reply with, I'll post there. No point
in making it excessively hard to get a simple answer if it doesn't
become a pattern.
On
*First of all why ASF ownership? *
For the project of this size maintaining high quality (it is not hard to
use stubgen or monkeytype, but resulting annotations are rather
simplistic) annotations independent of the actual codebase is far from
trivial. For starters, changes which are mostly
Hello Everyone,
Someone asked this question on JIRA and since it was a question I requested
him to check stack overflow. Personally I don't have an answer to this
question so in case anyone has an idea please feel free to update the
issue. I have marked it resolved for the time being but thought
Maybe more specifically, why an ASF repo?
On Tue, Aug 4, 2020 at 11:45 AM Felix Cheung wrote:
>
> What would be the reason for separate git repo?
>
>
> From: Hyukjin Kwon
> Sent: Monday, August 3, 2020 1:58:55 AM
> To: Maciej Szymkiewicz
> Cc: Driesprong, Fokko
Thanks! That's exactly what I was hoping for! Thanks for finding the Jira
for me!
On Tue, Aug 4, 2020 at 11:46 AM Wenchen Fan wrote:
> I think this is not a problem in 3.0 anymore, see
> https://issues.apache.org/jira/browse/SPARK-27638
>
> On Wed, Aug 5, 2020 at 12:08 AM Russell Spitzer
>
Hi, Russell,
You might hit the other cases in which CAST blocks the predicate pushdown.
If the Cast was added by users and it changes the actual type, we are
unable to optimize it automatically because it could change the query
correctness. If it was added by our type coercion rules
I think this is not a problem in 3.0 anymore, see
https://issues.apache.org/jira/browse/SPARK-27638
On Wed, Aug 5, 2020 at 12:08 AM Russell Spitzer
wrote:
> I've just run into this issue again with another user and I feel like most
> folks here have seen some flavor of this at some point.
>
>
What would be the reason for separate git repo?
From: Hyukjin Kwon
Sent: Monday, August 3, 2020 1:58:55 AM
To: Maciej Szymkiewicz
Cc: Driesprong, Fokko ; Holden Karau
; Spark Dev List
Subject: Re: [PySpark] Revisiting PySpark type annotations
Okay, seems like
I've just run into this issue again with another user and I feel like most
folks here have seen some flavor of this at some point.
The user registers a Datasource with a column of type Date (or some non
string) then performs a query that looks like.
*SELECT * from Source WHERE date_col >
Sure, but these are English words. I don't think anybody argues that
it should be an issue to _everyone_, perhaps you. But you seem to
suggest that it shouldn't be an issue to _anyone_ because it isn't an
issue to many people. I don't think that works either. Ex: if someone
proposed a fix to the
Hi Sean!
Your point is good and I accept it, but I thought it worth to remind yet
again that ASF isn't limited by the US and the world is not limited by
English language and as the result shouldn't be limited by some people's
personal issue - there are specialists around who can help with these.
I know this kind of argument has bounced around not just within the
ASF but outside too. While we should feel open to debate here, even if
I don't think it will get anywhere new, let me suggest it won't matter
to the decision process here, so, not worth it.
We should discuss this type of change
I think we should use Scheduler or Comptroller or Leader; something that
evokes better describes the purpose as a resource management service. I
would rather we didn't use controller, coordinator, application manager,
primary because I feel that those terms make it seem like the process is
central
Just no changes? Name provides no issues and is pretty clear about its
intentions. Racist links are quite overminded.
--
,,^..^,,
On Tue, Aug 4, 2020 at 5:19 PM Tom Graves
wrote:
> Hey Folks,
>
> We have jira https://issues.apache.org/jira/browse/SPARK-32037 to rename
> the blacklisting
Hey Folks,
We have jira https://issues.apache.org/jira/browse/SPARK-32037 to rename the
blacklisting feature. It would be nice to come to a consensus on what we want
to call that.It doesn't looks like we have any references to whitelist other
then from other components. There is some
I think this is a good idea, and yes keeping it backwards compatible
initially is important since we missed the boat on Spark 3. I like the
Controller/Leader one since I think that does a good job of reflecting the
codes role.
On Tue, Aug 4, 2020 at 7:01 AM Tom Graves
wrote:
> Hey everyone,
>
>
Hey everyone,
I filed jira https://issues.apache.org/jira/browse/SPARK-32333 to remove
references to Master. I realize this is a bigger change then the slave jira
but I wanted to get folks input on if they are ok with making the change and if
so we would need to pick a name to use instead. I
24 matches
Mail list logo
