minor clarification: content from GPT might be valuable - what I meant was, the value of content from GPT "in the community". The content is either something people in the thread knows, or something they can query to GPT on their own. Though I barely use GPT for the query which matters with expertise.
On Thu, Oct 10, 2024 at 9:27 AM Jungtaek Lim <kabhwan.opensou...@gmail.com> wrote: > +1 on this. > > I'd ask people to quote the part you got from GPT and explicitly call out > the part as "GPT-generated" so that people would consider that there is > hallucination. Do not ever expect that people wouldn't know the content GPT > wrote. "People know." > > ASF requires every code contribution to explicitly call out if GPT is ever > involved, so I think this is somehow in sync with the direction of ASF > (though what ASF concerns for code contribution is mostly about license). > > ps. personally I don't see the value of content from GPT - GPT is > available for everyone. People ask questions for very simple things which > GPT would help, but in many of the cases the question requires expertise to > answer. I don't think GPT has evolved yet to handle this case properly > (which I feel relieved ;) ). > > > On Thu, Oct 10, 2024 at 1:53 AM Sean Owen <sro...@apache.org> wrote: > >> Agree, I can't really explain this post except as AI hallucination, >> because: >> >> - those configs don't exist and it's not a simple typo away from a real >> one >> - they are kind of like unrelated real Spark config names and the kind of >> thing it seems an AI would 'infer' >> - no claim it was a typo with plausible real answer that was intended >> - it's happened before in the same way >> >> We don't sanction occasional good faith mistakes. I don't think it's any >> problem to use AI to help edit answers, either. >> But misleading posts to such a big list, whatever the source, is a >> problem if it's a pattern. >> >> Even merely distracting posts seem like a problem to me. For example, >> this looks like an AI response: >> https://lists.apache.org/thread/o0slbb9rw5qdjzl896041vfkbv30lqgw I think >> it's more unuseful than anything, not specifically wrong, though I think it >> makes dubious statements with no backup ("for performance-critical >> scenarios, GraphX should still be considered" ?) that are not particularly >> relevant to the discussion. >> >> We did discuss this when it has happened in the past and Mich claimed >> there is no AI here. I don't find this credible, but regardless, let us say: >> >> 1. All: don't post substantially AI generated content as-is. Anything >> authored with AI needs to be 'fact checked' at least. If you're mostly >> writing with AI, ask if you have enough to say to warrant posting. >> 2. Mich take the feedback about some of your posts' accuracy and value >> and consider this when deciding what to post in the future, instead of >> criticizing the feedback >> >> On Wed, Oct 9, 2024 at 11:13 AM Nicholas Chammas < >> nicholas.cham...@gmail.com> wrote: >> >>> Mich, >>> >>> You are “helping” someone by giving them configs that don’t exist. And >>> this is the second time >>> <https://lists.apache.org/thread/6hmfmz6owy3jb5y0zx9j307bc38wj54f> that >>> I am aware of that you are doing this. >>> >>> Both times you have done this and I have asked you to explain where you >>> are getting these non-existent configs from, you have declined to share. >>> >>> To me it looks like you are posting ChatGPT/genAI gibberish without >>> vetting it and confirming it is correct information. And you do this to the >>> detriment of everyone on the list. It actively harms newcomers looking for >>> help by sending them on wild goose chases. And it insults the intelligence >>> of the contributors and committers who expect a high signal to noise ratio >>> on this list. >>> >>> Please STOP posting genAI nonsense to the list. If you do not have >>> direct knowledge of the subject being discussed in a thread, don’t >>> participate in the thread. It’s that simple. If you want to use genAI to >>> help craft a response, carefully vet the information before you post it as >>> your own. >>> >>> Dev list admins, >>> >>> Could the list admins please chime in with an “official” take on this >>> behavior? I hate to be the one to start this discussion, but I do it >>> because a) it’s the second time it has happened (that I am personally aware >>> of), and b) it’s very counterproductive and lowers the quality of the >>> discussions on the list. >>> >>> Nick >>> >>> >>> On Oct 9, 2024, at 6:51 PM, Mich Talebzadeh <mich.talebza...@gmail.com> >>> wrote: >>> >>> Do you have a better recommendation? >>> >>> Or trying to waste time as usual. >>> >>> It is far easier to throw than catch. >>> >>> Do your homework and stop throwing spanners at work. >>> >>> Mich Talebzadeh, >>> >>> Architect | Data Engineer | Data Science | Financial Crime >>> PhD <https://en.wikipedia.org/wiki/Doctor_of_Philosophy> Imperial >>> College London <https://en.wikipedia.org/wiki/Imperial_College_London> >>> London, United Kingdom >>> >>> view my Linkedin profile >>> <https://www.linkedin.com/in/mich-talebzadeh-ph-d-5205b2/> >>> >>> >>> https://en.everybodywiki.com/Mich_Talebzadeh >>> >>> >>> >>> *Disclaimer:* The information provided is correct to the best of my >>> knowledge but of course cannot be guaranteed . It is essential to note >>> that, as with any advice, quote "one test result is worth one-thousand >>> expert opinions (Werner >>> <https://en.wikipedia.org/wiki/Wernher_von_Braun>Von Braun >>> <https://en.wikipedia.org/wiki/Wernher_von_Braun>)". >>> >>> >>> On Wed, 9 Oct 2024 at 16:43, Nicholas Chammas < >>> nicholas.cham...@gmail.com> wrote: >>> >>>> Mich, >>>> >>>> Can you please share with the list where *exactly* you are citing >>>> these configs from? >>>> >>>> As far as I can tell, these two configs don’t exist and have never >>>> existed in the Spark codebase: >>>> >>>> spark.executor.decommission.enabled=true >>>> spark.executor.decommission.gracefulShutdown=true >>>> >>>> Where exactly are you getting this information from (and then posting >>>> it to the list as advice)? Please be clear and provide specific references. >>>> >>>> Nick >>>> >>>> >>>> On Oct 9, 2024, at 1:20 PM, Mich Talebzadeh <mich.talebza...@gmail.com> >>>> wrote: >>>> >>>> Before responding, what configuration parameters are you using to make >>>> this work? >>>> >>>> spark.executor.decommission.enabled=true >>>> spark.executor.decommission.gracefulShutdown=true >>>> spark.executor.decommission.forceKillTimeout=100s >>>> >>>> HTH >>>> >>>> Mich Talebzadeh, >>>> >>>> Architect | Data Engineer | Data Science | Financial Crime >>>> PhD <https://en.wikipedia.org/wiki/Doctor_of_Philosophy> Imperial >>>> College London <https://en.wikipedia.org/wiki/Imperial_College_London> >>>> London, United Kingdom >>>> >>>> view my Linkedin profile >>>> <https://www.linkedin.com/in/mich-talebzadeh-ph-d-5205b2/> >>>> >>>> >>>> https://en.everybodywiki.com/Mich_Talebzadeh >>>> >>>> >>>> >>>> *Disclaimer:* The information provided is correct to the best of my >>>> knowledge but of course cannot be guaranteed . It is essential to note >>>> that, as with any advice, quote "one test result is worth one-thousand >>>> expert opinions (Werner >>>> <https://en.wikipedia.org/wiki/Wernher_von_Braun>Von Braun >>>> <https://en.wikipedia.org/wiki/Wernher_von_Braun>)". >>>> >>>> >>>> On Wed, 9 Oct 2024 at 11:05, Jay Han <tunyu...@gmail.com> wrote: >>>> >>>>> Hi spark community, >>>>> I have such a question: Why driver doesn't shutdown executors >>>>> gracefully on k8s. For instance, >>>>> kubernetesClient.pods().withGracePeriod(100).delete(). >>>>> >>>>> >>>>> -- >>>>> Best, >>>>> Jay >>>>> >>>> >>>> >>>
