Thank you Wenchen for the input.. I can understand this, and I accepted this long back. The first PR which I opened related to constraints propagation issue was in 21 , I guess. Since then I have filed PRs regularly.. I have no issues , it not getting reviewed or ignored.. If I was so desperate to get PRs in , I would be pestering dev group from year 21.. last I counted, I had some 26-30 tickets filed and may be 20+ PRs.
The issues are 1) advertently or inadvertently, the exact issue solved using a new ticket and by some one else, and using same solution 2) if the issue and or is reviewed, then under some pretext or another , attempting to take over the PR and hence authorship I have given multiple examples as asked by one member. And as I said, I am willing to discuss each and every PR I have opened, with the members and defend it against the alternate PRs filed. I firmly am of opinion that this is unethical and credit stealing . All the heavy lifting is done by some one, and in the end it's hijacked . And again , atleast I am not looking for appreciation ( that is a favour being done, and I am not looking for that), its the credit which is the original author's right, unless the PR created is totally wrong. And in my case, I would welcome any one from the group to prove any of my PR as incorrect. Regards Asif On Fri, May 29, 2026, 11:18 PM Wenchen Fan <[email protected]> wrote: > I can understand the frustration of PRs being ignored while authors have > put a lot of effort on it. In an ideal world, all PRs deserve a decent > review/discussion from the community and at least one committer, so that > the PR can get merged or rejected with a clear reason. However, the reality > is: committers have limited time and attention, actively monitoring all > open PRs and JIRAs is nearly impossible. I just checked and there are 360+ > open PRs right now. > > I don't have a good solution here. I've been trying my best to review PRs > that ping me, but there is no guaranteed review (sometimes I was just too > tired, or misclicked the "mark as read" button). I don't think there is a > "control" here, it's all about how you can get attention. Building your > credibility with small tasks (which gets attention easier) is one way. @huaxin > gao <[email protected]> is proposing a Monthly Spark Community Sync, > which may be a good place to present complex PRs/proposals and get > attention. > > On Sat, May 30, 2026 at 12:29 AM Asif Shahid <[email protected]> > wrote: > >> This control , exclusivity, the requirement to build credibility by >> starting small ( like fixing formatting , stats ,log) , to leave complex >> issues to other " bright " minds, the informal hierarchy, may be this is >> how the open source works. >> Whatever it's , it does not sound "community " to me. >> This is a club ( cartel is offensive to some or most), with usual >> struggle for power , control and politics. >> >> On Fri, May 29, 2026, 8:31 AM Asif Shahid <[email protected]> wrote: >> >>> The last line is to be read as >>> >>> >>> That is how exclusivity and good control is to be maintained. >>> >>> On Fri, May 29, 2026, 8:29 AM Asif Shahid <[email protected]> wrote: >>> >>>> To the open source C, >>>> As it's apparent to me and I believe tacitly admitted by the group in >>>> general and heard explicitly in person >>>> Any relatively complex PR which involves deeper thinking ( be it >>>> functional or performance issue) should be the business of member. >>>> If it's performance issue , no way . >>>> If it's functional issue which is becoming embarrassment to ignore, >>>> somehow ensure that the push happens under a member's PR. >>>> >>>> That is how exclusivity and good is to be maintained. >>>> >>>> >>>> On Fri, May 29, 2026, 8:05 AM Asif Shahid <[email protected]> >>>> wrote: >>>> >>>>> Based on the data I have and discussed, it's my view that the PRs >>>>> opened by you were reactive, happening only after I had opened the initial >>>>> ticket and PRs. >>>>> You are talking about simplifying the issue >>>>> https://github.com/apache/spark/pull/50757#discussion_r2069390537, >>>>> I am willing to discuss it here ,over meeting with other members of >>>>> your open source group, as to how it simplifies? >>>>> >>>>> In fact , I had repeatedly said that why are we discussing in >>>>> internal channel of company for the PR which I had filed in public Open >>>>> source . In that discussion ( the last one, before I was made redundant by >>>>> company), I had given detailed explanation of why making each plan node >>>>> emit indeterministic is bad idea. ( I would ask you to make that last >>>>> slack public, but I am sure that would be an issue as your company policy >>>>> might prohibit). >>>>> >>>>> I understood much earlier why you and your colleague never wanted >>>>> technical discussions on my public PRs on PR itself.. >>>>> >>>>> >>>>> >>>>> The same holds for other alternate PRs including the issue of "self >>>>> joins". >>>>> I am willing to discuss it out with your group members, the problem it >>>>> solves and what your alternative PR does not. >>>>> >>>>> >>>>> I am not sure if this is generic approach of the "members", to ensure >>>>> that final checkin happens under their authorship. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, May 29, 2026, 1:58 AM Peter Toth <[email protected]> wrote: >>>>> >>>>>> Hi Viquar, >>>>>> >>>>>> To resolve the immediate discrepancy, I ask that we formally link >>>>>>> SPARK-45866 / PR #49154 within SPARK-56694 as "previously proposed by," >>>>>>> and >>>>>>> add a JIRA comment explicitly crediting Asif as the original >>>>>>> co-discoverer >>>>>>> of both the regression and the baseline fix. This standard attribution >>>>>>> costs us nothing but preserves the integrity of our commit history. >>>>>> >>>>>> >>>>>> SPARK-56694 is a duplicate of SPARK-45658 (not SPARK-45866), but I >>>>>> agree it's a fair point to link the tickets and mention Asif's previous >>>>>> work. Let me add a comment to both the ticket and the PR. >>>>>> >>>>>> Conversely, SPARK-56694 bypassed the queue and was merged within >>>>>>> eight hours >>>>>> >>>>>> >>>>>> I don't know, is there a queue? As for my work process, when I have >>>>>> some time for upstream reviews, I don't follow any queue. I just pick PRs >>>>>> that I find interesting or that relate to my experience with Spark. And >>>>>> despite its size, https://github.com/apache/spark/pull/55644/changes >>>>>> is technically just a one-liner, fairly trivial fix so review within 8 >>>>>> hours isn't extraordinary. >>>>>> >>>>>> Hi Asif, >>>>>> >>>>>> you opened an alternate PR, which... >>>>>>> >>>>>> What issue did u see in the logic, that an alternate PR was opened... >>>>>> >>>>>> >>>>>> I think the reason for my simplification approach was discussed both >>>>>> offline and online in this thread: >>>>>> https://github.com/apache/spark/pull/50757#discussion_r2069390537 >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Best, >>>>>> Peter >>>>>> >>>>>> On Thu, May 28, 2026 at 10:29 PM vaquar khan <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I have thoroughly reviewed the technical artifacts surrounding the >>>>>>> recent Catalyst optimizer canonicalization discussions to help guide >>>>>>> this >>>>>>> toward a constructive resolution. >>>>>>> >>>>>>> We must address a tangible breakdown in our review pipeline. >>>>>>> SPARK-45866 and its corresponding PR #49154 correctly identified this >>>>>>> complex Catalyst regression in late 2023, yet the ticket remained >>>>>>> unaddressed. *Conversely, SPARK-56694 bypassed the queue and was >>>>>>> merged within eight hours without referencing the prior art*. Peter >>>>>>> has transparently acknowledged the oversight in searching for existing >>>>>>> tickets, but we still need to close the loop. >>>>>>> >>>>>>> To resolve the immediate discrepancy,* I ask that we formally link >>>>>>> SPARK-45866 / PR #49154 within SPARK-56694 as "previously proposed by," >>>>>>> and >>>>>>> add a JIRA comment explicitly crediting Asif as the original >>>>>>> co-discoverer >>>>>>> of both the regression and the baseline fix. This standard attribution >>>>>>> costs us nothing but preserves the integrity of our commit history. * >>>>>>> >>>>>>> Stepping back, this incident highlights a critical systemic risk to >>>>>>> our contributor ecosystem. The stark asymmetry in review velocity where >>>>>>> an >>>>>>> external contributor's highly complex PR sits stagnant for months/years, >>>>>>> while an identical internal PR is merged in hours creates visible >>>>>>> friction. >>>>>>> Even if entirely unintentional due to organizational overload, this >>>>>>> pattern >>>>>>> discourages the high-level engineering talent required to sustain the >>>>>>> project's momentum. >>>>>>> >>>>>>> To maintain Spark’s technical leadership, we must actively cultivate >>>>>>> a culture where contributions are prioritized strictly by their >>>>>>> architectural merit, regardless of authorship. Furthermore, we must >>>>>>> normalize the habit of proactively acknowledging independent work when >>>>>>> parallel discoveries surface. Small, intentional shifts in our >>>>>>> governance >>>>>>> and review cadence will yield massive dividends in community trust and >>>>>>> long-term innovation. >>>>>>> >>>>>>> Best regards, >>>>>>> Viquar Khan >>>>>>> https://www.linkedin.com/in/vaquar-khan-b695577/?skipRedirect=true >>>>>>> >>>>>>> >>>>>>> On Thu, 28 May 2026 at 13:42, Asif Shahid <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Also I must admit that I did not know oss works by opening >>>>>>>> alternate PRs. >>>>>>>> In the places where I have worked most of my life, we work on the >>>>>>>> opened PR with the original author and try to bridge the gap. >>>>>>>> >>>>>>>> On Thu, May 28, 2026, 11:25 AM Asif Shahid <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> In fact, I showed it not just to you but other colleague of yours >>>>>>>>> too. But there has been absolutely no comment or anything on that >>>>>>>>> from >>>>>>>>> then , till now. >>>>>>>>> >>>>>>>>> On Thu, May 28, 2026 at 11:19 AM Asif Shahid < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> also take a look at this jira >>>>>>>>>> https://issues.apache.org/jira/browse/SPARK-47320 >>>>>>>>>> for this also an alternate PR was opened. >>>>>>>>>> This problem is do deep in code, that I even showed you that in >>>>>>>>>> the existing test itself, if the join condition's operand are >>>>>>>>>> swapped, test >>>>>>>>>> fails.. Its completely broken , the self joins. >>>>>>>>>> I had proposed a consistent fix, which solves the issue >>>>>>>>>> completely and logically, but again an alternate PR was filed.. >>>>>>>>>> What issue was there in my PR , which I created...? >>>>>>>>>> Regards >>>>>>>>>> Asif >>>>>>>>>> >>>>>>>>>> On Thu, May 28, 2026 at 11:14 AM Asif Shahid < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, May 28, 2026 at 10:56 AM Peter Toth < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As for the fix, itself, is not indicative of any thing as its a >>>>>>>>>>>>> one liner, test has uncanny resemblance >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Asif, what exactly is the "uncanny resemblance" between those >>>>>>>>>>>> test cases in >>>>>>>>>>>> https://github.com/apache/spark/pull/49154/changes vs >>>>>>>>>>>> https://github.com/apache/spark/pull/55644/changes ? Besides >>>>>>>>>>>> the fact that obviously they are comparing canonicalized forms. >>>>>>>>>>>> Again, sorry for not noticing your PR, but I don't feel my fix >>>>>>>>>>>> has anything to do with yours. >>>>>>>>>>>> >>>>>>>>>>> Ok. I respect your opinion. Each one is entitled to its own >>>>>>>>>>> view >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1) Look at bug >>>>>>>>>>>>> https://issues.apache.org/jira/browse/SPARK-51016 >>>>>>>>>>>>> To discover this bug and reproduce it reliably, I spent nearly >>>>>>>>>>>>> 2- 3 weeks. I filed a PR. The bug was fixed via a different PR , >>>>>>>>>>>>> taken a >>>>>>>>>>>>> different route. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Do you see anything in common between >>>>>>>>>>>> https://github.com/apache/spark/pull/50029/changes and >>>>>>>>>>>> https://github.com/apache/spark/pull/50757/changes ? >>>>>>>>>>>> Because I do see. That someone else had a much better idea: >>>>>>>>>>>> https://github.com/apache/spark/pull/50757#issuecomment-2844972082 >>>>>>>>>>>> / https://github.com/apache/spark/pull/50230 and it was >>>>>>>>>>>> implemented for the benefit of Spark. >>>>>>>>>>>> IMO, that's the normal way of dealing with issues in an >>>>>>>>>>>> open-source project. Ideas come and go and hopefully the one best >>>>>>>>>>>> wins. >>>>>>>>>>>> >>>>>>>>>>> The checksum approach has its expense. That can come later , >>>>>>>>>>> because apriori its possible to detect whether the expression is >>>>>>>>>>> returning >>>>>>>>>>> value from an indeterministic expression. >>>>>>>>>>> You opened an alternate PR, which I have described in the PR >>>>>>>>>>> discussion that to fix the round robin issue which you were dealing >>>>>>>>>>> with, >>>>>>>>>>> you are trying to impose an order in in-deterministic expression >>>>>>>>>>> evaluattion, which itself is against the basic premise that if data >>>>>>>>>>> is >>>>>>>>>>> in-determinate, there cannot be order in it. >>>>>>>>>>> What issue did u see in the logic, that an alternate PR was >>>>>>>>>>> opened...which impacted all the stages ( including the ancestors?) >>>>>>>>>>> and I >>>>>>>>>>> already discussed internally why the idea you had in mind would not >>>>>>>>>>> work. I >>>>>>>>>>> specifically asked, why dont we discuss via the PR filed... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Peter >>>>>>>>>>>> >>>>>>>>>>>> On Thu, May 28, 2026 at 6:38 PM Asif Shahid < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Nicholas, >>>>>>>>>>>>> You wanted some examples , right: >>>>>>>>>>>>> 1) Look at bug >>>>>>>>>>>>> https://issues.apache.org/jira/browse/SPARK-51016 >>>>>>>>>>>>> To discover this bug and reproduce it reliably, I spent nearly >>>>>>>>>>>>> 2- 3 weeks. I filed a PR. The bug was fixed via a different PR , >>>>>>>>>>>>> taken a >>>>>>>>>>>>> different route. >>>>>>>>>>>>> Did any one who created new PR and route, showed up any >>>>>>>>>>>>> unaddressable logical issue? >>>>>>>>>>>>> The same goes for all the PRs ( which in case I have closed) >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Asif >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, May 28, 2026 at 9:06 AM Nicholas Chammas < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I think repeatedly calling the contributors on this list a >>>>>>>>>>>>>> “cartel” is not conducive to a calm and amicable resolution. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You may have some history built up that led you to use that >>>>>>>>>>>>>> word, but to the rest of us it comes out of nowhere; you in fact >>>>>>>>>>>>>> opened >>>>>>>>>>>>>> this thread with that attack. If you keep making your case in >>>>>>>>>>>>>> this manner, >>>>>>>>>>>>>> you will just turn everyone against you. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If there is a history of what you feel is others stealing >>>>>>>>>>>>>> your work, please link to a few examples so we can see what you >>>>>>>>>>>>>> are seeing. >>>>>>>>>>>>>> If you can’t do that, then just focus on this current example. >>>>>>>>>>>>>> And try to >>>>>>>>>>>>>> refrain from calling people names unless your goal is just to >>>>>>>>>>>>>> have a fight, >>>>>>>>>>>>>> as opposed to resolving the problematic behavior so you can >>>>>>>>>>>>>> continue to >>>>>>>>>>>>>> contribute. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am not a committer and don’t have any special role in this >>>>>>>>>>>>>> community. I am speaking just as an observer and regular >>>>>>>>>>>>>> contributor to the >>>>>>>>>>>>>> project. >>>>>>>>>>>>>> >>>>>>>>>>>>>> > I have experienced this before, as recent as couple of >>>>>>>>>>>>>> months back ( >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/SPARK-54386) >>>>>>>>>>>>>> >>>>>>>>>>>>>> For others following along, I took a look at this ticket and >>>>>>>>>>>>>> the associated PRs: #53261 >>>>>>>>>>>>>> <https://github.com/apache/spark/pull/53261> / #53100 >>>>>>>>>>>>>> <https://github.com/apache/spark/pull/53100> >>>>>>>>>>>>>> >>>>>>>>>>>>>> It looks like Asif is upset that he submitted a fix for the >>>>>>>>>>>>>> same issue a week or so prior to the fix that eventually got >>>>>>>>>>>>>> merged. But >>>>>>>>>>>>>> the fixes are different, and the one that got merged is a lot >>>>>>>>>>>>>> shorter, >>>>>>>>>>>>>> though they are both simple. The PR that got merged was >>>>>>>>>>>>>> submitted by >>>>>>>>>>>>>> someone who appears to be employed by Databricks; perhaps this >>>>>>>>>>>>>> is part of >>>>>>>>>>>>>> the “cartel” accusation. The two PRs were reviewed by different >>>>>>>>>>>>>> committers, >>>>>>>>>>>>>> however, and the one that got merged was merged in by someone >>>>>>>>>>>>>> who does >>>>>>>>>>>>>> _not_ work for Databricks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don’t see anything here other than the normal dynamic of a >>>>>>>>>>>>>> large and busy open source project. Committer attention is >>>>>>>>>>>>>> limited; things >>>>>>>>>>>>>> fall through the cracks; different contributors may occasionally >>>>>>>>>>>>>> work on >>>>>>>>>>>>>> the same thing without knowing about each other. A minor help to >>>>>>>>>>>>>> this >>>>>>>>>>>>>> specific problem would be to have some way of automatically >>>>>>>>>>>>>> linking issues >>>>>>>>>>>>>> that appear to be about the same thing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nick >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On May 28, 2026, at 11:33 AM, Asif Shahid < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Peter, >>>>>>>>>>>>>> Pls see inline for comments/ replies >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, May 28, 2026 at 6:11 AM Peter Toth < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hey Asif, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Are you referring to >>>>>>>>>>>>>>> https://github.com/apache/spark/pull/49154/changes vs. >>>>>>>>>>>>>>> https://github.com/apache/spark/pull/55644/changes? Those >>>>>>>>>>>>>>> are definitely solving the same issue but I can assure you I >>>>>>>>>>>>>>> wouldn't take >>>>>>>>>>>>>>> any code from your PR without consulting with you first. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes Indeed Peter, I am referring to those. >>>>>>>>>>>>>> As for the fix, itself, is not indicative of any thing as its >>>>>>>>>>>>>> a one liner, test has uncanny resemblance. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> As far as I remember, I opened SPARK-56694 / >>>>>>>>>>>>>>> https://github.com/apache/spark/pull/55644 because I ran >>>>>>>>>>>>>>> into that minor bug during the implementation of >>>>>>>>>>>>>>> https://github.com/apache/spark/pull/55298. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sorry, I didn't check whether a ticket or PR already existed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The below I am addressing to the whole cartel.: >>>>>>>>>>>>>> I have experienced this before, as recent as couple of months >>>>>>>>>>>>>> back ( https://issues.apache.org/jira/browse/SPARK-54386) >>>>>>>>>>>>>> I have experienced, my personal effort ( going into weeks) >>>>>>>>>>>>>> to debug, reproduce issue reliably , being hijacked by members, >>>>>>>>>>>>>> without >>>>>>>>>>>>>> even discussing the fix proposed, ( by opening new PRs). ( If >>>>>>>>>>>>>> interested, I >>>>>>>>>>>>>> can provide details of the PRs / issues I am talking about) >>>>>>>>>>>>>> I have seen a perfectly valid PR being nixed , by following >>>>>>>>>>>>>> comment which essentially said >>>>>>>>>>>>>> " my code of making the cache lookup more effective , would >>>>>>>>>>>>>> result in greater chances of stale cache being picked, which >>>>>>>>>>>>>> already spark >>>>>>>>>>>>>> suffers from." >>>>>>>>>>>>>> Now the PR was related to collapsing the projects in analysis >>>>>>>>>>>>>> phase, and side effect was cache pick up being more sensitive. >>>>>>>>>>>>>> So this is such a frivolous reason to nix the PR , because >>>>>>>>>>>>>> "staleness" is an underlying existing issue which had nothing to >>>>>>>>>>>>>> do with my >>>>>>>>>>>>>> PR. And its more amusing , that if a DB is giving even one wrong >>>>>>>>>>>>>> result in >>>>>>>>>>>>>> millions, that makes all the results a suspect in any case. It >>>>>>>>>>>>>> does not >>>>>>>>>>>>>> matter at what frequency this occurs. To me the real reason was >>>>>>>>>>>>>> code >>>>>>>>>>>>>> complexity ( & more likely the loss of control of the code to >>>>>>>>>>>>>> the >>>>>>>>>>>>>> outsider). >>>>>>>>>>>>>> >>>>>>>>>>>>>> The reason I call this open source community as cartel, is >>>>>>>>>>>>>> because, I have seen the way it works pretty closely and have >>>>>>>>>>>>>> experienced >>>>>>>>>>>>>> it in the email exchanges which happen on this group. >>>>>>>>>>>>>> For the same PR , same issue, if advertently or >>>>>>>>>>>>>> inadvertently , other person ( especially a member) gets his >>>>>>>>>>>>>> changes >>>>>>>>>>>>>> pushed, by the virtue of his standing/position and the "for >>>>>>>>>>>>>> profit" company >>>>>>>>>>>>>> the person works, how would you give the credit to the original >>>>>>>>>>>>>> person who >>>>>>>>>>>>>> discovered the issue first / provided the fix? >>>>>>>>>>>>>> Why are issues filed by some immediately worked upon by >>>>>>>>>>>>>> members ( some of whom claim to be working full time on spark) ? >>>>>>>>>>>>>> Is it >>>>>>>>>>>>>> because certain companies / groups ( for profit companies, mind >>>>>>>>>>>>>> you ) >>>>>>>>>>>>>> exert undue control, or the petty newbee has to be in the good >>>>>>>>>>>>>> books of >>>>>>>>>>>>>> members ( with the hope that at some point they will also reach >>>>>>>>>>>>>> that >>>>>>>>>>>>>> position of power ?) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Given the AI advent and such occurrences, how will you give >>>>>>>>>>>>>> due credit to the original creators and how do you plan to >>>>>>>>>>>>>> prevent some >>>>>>>>>>>>>> member for taking up idea of any old open PR ( which for reasons >>>>>>>>>>>>>> of >>>>>>>>>>>>>> complexity and non technical reasons) , polishing it up and >>>>>>>>>>>>>> pushing it as >>>>>>>>>>>>>> their own? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am also curious , am I the only one who is troubled by all >>>>>>>>>>>>>> this, or there are others who have experienced it? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Asif >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> If you have further improvements please feel free to open a >>>>>>>>>>>>>>> PR. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>> Peter >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, May 28, 2026 at 8:20 AM Asif Shahid < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> I had filed a bug >>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/SPARK-45866 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I had also opened a PR for the same. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Now I see that the ticket I filed is still open, but the >>>>>>>>>>>>>>>> issue has been fixed using a new ticket >>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/SPARK-56694 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> and on top of that the bug test and ofcourse the fix ( >>>>>>>>>>>>>>>> which in any case would be same) has been taken from my PR for >>>>>>>>>>>>>>>> https://github.com/apache/spark/pull/49154/changes#diff-137d880ff73623bf7a452bb84f9c3dbbb27ba929e7f5e070c6bff68cfc8ec71f >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To me this is clear unethical conduct of cartel member, >>>>>>>>>>>>>>>> unless I am missing some valid reason. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And the irony is that the fix is still incomplete, as I >>>>>>>>>>>>>>>> just found and filed a new ticket >>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/SPARK-57126 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I know that atleast some cartel members are insecure and >>>>>>>>>>>>>>>> think of OSS as their fiefdom, but this sort of behaviour , I >>>>>>>>>>>>>>>> never >>>>>>>>>>>>>>>> expected. >>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>> Asif >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>
