[HN Gopher] Giving up upstream-ing my patches and feel free to p...
___________________________________________________________________
Giving up upstream-ing my patches and feel free to pick them up
Author : csmantle
Score : 120 points
Date : 2026-01-31 10:53 UTC (12 hours ago)
(HTM) web link (mail.openjdk.org)
(TXT) w3m dump (mail.openjdk.org)
| dwroberts wrote:
| The PRs they link mostly seem like noise? "Remove the d prefix
| from this number because the C++ standard doesn't require it".
| Yeah great.
| jstanley wrote:
| That's a pretty unfair characterisation of the commit in
| question:
| https://github.com/loongson/jdk/pull/125/commits/ee300a6ce73...
|
| By my reading, it's not merely that the standard doesn't
| _require_ the "d" suffix, it's that the standard doesn't
| _allow_ the "d" suffix, and the code won't compile on anything
| but gcc.
| freedomben wrote:
| Agreed, although things I immediately think of are:
|
| 1. Is "anything but gcc" actually supported by the project?
| Do they have a goal of supporting other compilers or possibly
| an explicit decision _not_ to support other compilers?
|
| 2. If they do support other compilers, how did the "d" suffix
| make it in the first place? That's something I would expect
| the dev or CI to catch pretty quickly.
|
| 3. Does gcc behave any differently with the "d" suffix not
| there? (I would think a core dev would know that off the top
| of their head, so it's possible they looked at it and decided
| it wasn't worth it. One would hope they'd comment on the PR
| though if they did that). If it does, this could introduce a
| really hard-to-track-down bug.
|
| I'm not defending Oracle here (in fact I hate Oracle and
| think they are a scourge on humanity) but trying to approach
| this with an objective look.
| dundarious wrote:
| Given they have one to fix usage of llvm-config, I assume
| clang is also supported or being worked on.
| stuaxo wrote:
| That sort of patch is clearly fixing something that
| blocked him, and probably blocked many others who didn't
| get as far as trying to fix it.
|
| A project should take on useful small patches, thats how
| you onboard contributors.
| gf000 wrote:
| That again assumes a project is looking to onboard
| contributors.
|
| I absolutely get that it was an unfortunate interaction
| from the email writer's perspective, and it's really
| unfortunate.
|
| But there are a lot of concerns/bureaucracy, etc in case
| of large projects like this. It may just never got to the
| person responsible, because it is a cross-cutting concern
| (so no clear way to assign it to someone) with a low
| priority.
| dwroberts wrote:
| If all of these things are about making it build under clang
| though they need to better explain it or maybe group these
| changes together though.
|
| My initial comment was maybe unfair but I can completely
| sympathise with the maintainers etc. that separately these
| PRs look like random small edits (e.g. from a linter) with no
| specific goal
| imcritic wrote:
| Shouldn't small trivial changes be easier to review (and
| thus maybe even have higher prio)?
| gf000 wrote:
| If there is a single maintainer of the project, sure.
|
| If it's such a massively huge project like OpenJDK, then
| not really.
|
| You might also check how non-trivial it is to get a
| change into the Linux kernel.
| thethirdone wrote:
| The d suffix makes it not compile under clang. The PRs seem
| like mostly small changes that are clear improvements.
| ablob wrote:
| The correct quote is: "Remove invalid 'd' suffix for double
| literals".
| perryprog wrote:
| Even if the changes aren't "meaningful" (which it seems like
| they are), they still have an impact in how it makes the
| contributor more comfortable with working on the project. No
| new contributor is going to start with making massive patches
| without starting out with some smaller things to get a feel for
| working with the project.
| Twirrim wrote:
| Agreed, these seem like ideal patches to me for a first
| contribution. Solves a specific problem, doesn't require a
| lot of effort on maintainers side to review, and should give
| them a straightforward path to familiarise themselves with
| the process.
| freedomben wrote:
| All of the https://github.com/AOSC-Tracking/jdk/ links 404 for
| me, so it's difficult to get a sense of what was being done.
| Going off of the "loongson fork" links though they look rather
| trivial. Not saying they should be ignored, but I do think
| trivial PRs to large critical open source projects like JDK can
| often end up taking more time away from contributing engineers
| doing reviews and testing than they are worth.
|
| I know first-hand the frustration of having PRs ignored and it
| can be quite demoralizing, so I do feel for the author. It sounds
| like the author is getting to a place of peace with it, and my
| advice from having been down that path before is to do exactly
| that, and find something else interesting to hack on.
| aeurielesn wrote:
| I disagree. Trivial PRs are perfect for first contributions,
| especially to get through the myriad of bots requesting you to
| sign/review stuff.
|
| Having said that, I would never contribute to a project with a
| first contributor experience like this one.
| zbentley wrote:
| I don't think you and GP disagree. Trivial PRs can be
|
| > perfect for first contributions, especially to get through
| the myriad of bots requesting you to sign/review stuff
|
| At the same time as they
|
| > can often end up taking more time away from contributing
| engineers doing reviews and testing than they are worth
| plagiarist wrote:
| I agree but I would also never contribute to a project with a
| CLA in the first place.
| Cpoll wrote:
| But that's not what's happening here, right? They're blocked on
| having their 'Oracle Contributer Agreement' approved; they're
| not even at the stage where their PRs are eligible for being
| ignored.
| rendaw wrote:
| Regardless of the contents,
|
| > For each of my emails, I got a reply, saying that they
| "sincerely apologize" and "@Dalibor Topic Can you please
| review...", with no actual progress being made.
|
| then
|
| > Sorry to hear this. .... @Dalibor Topic <dalibor.topic at
| oracle.com>, can we get this prioritized?
|
| This is pretty morbidly funny.
| softwaredoug wrote:
| Anyone who has been a freelancer negotiating a contract with a
| big company feels this sort of thing in their bones.
| krater23 wrote:
| Never had this issue. Its just as simple as start to work
| without contract and the promise of department head to get a
| contract and after two weeks mention to the contracting that
| you work since two weeks and have still not signed a NDA.
|
| Next sentence is: I don't fear to not get my money, but
| currently I don't know if you pay or someone else...
| NooneAtAll3 wrote:
| compiler error: `since(time_point_t)` cannot be called with
| `time_duration_t`
|
| were you trying to use `for(time_duration_t)` ?
| voakbasda wrote:
| When I want to contribute to an open source project, I throw
| together some trivial but useful patches and see how the project
| responds.
|
| Many projects behave this way, particularly those with corporate
| overlords. At best, it will take weeks to get a simple patch
| reviewed. By then, I have moved on, at least with my intention to
| send anything upstream. I commend the author for giving them a
| whole year, but I have found that is best a recipe for
| disappointment.
|
| Maintainers: how you react to patches and PRs significantly
| influence whether or not you get skilled contributors. When I was
| maintaining such projects, I always tried to reply within 24
| hours to new contributors.
|
| It would be interesting to see how quickly the retention rate
| drops off as the time to review/accept patches goes up. I imagine
| it looks like an exponential drop off.
| esafak wrote:
| Absolutely. I look at the commit and PR history. Are the
| maintainers responsive and welcoming?
| IshKebab wrote:
| Have you found this actually works? I wouldn't be surprised if
| many projects happily accept trivial PRs (because they're easy
| to deal with) but then ignore or naysay anything more
| substantial.
| Brian_K_White wrote:
| The point is only 50% to see if they respond, it's also to
| start establishing yourself as a known entity to them.
|
| They will ignore a big patch from a rando and obviously
| process a big patch from themselves.
|
| You can become somehwere in between and no longer be a rando,
| but have to start from the rando end.
| pjm331 wrote:
| I have this theory that with LLMs getting better at writing code
| our current open source model (relatively few large projects that
| everyone contributes to, relatively rare to maintain your own
| fork) will invert and it will be easier and more common for
| people to have personalized forks and a lot of the problems
| around managing large open source projects will just become
| irrelevant
| majormajor wrote:
| Or a ton of "personalized agents" will start bugging upstream
| to complain about suspected issues with all those forks all the
| time...
| beart wrote:
| I know Java has a complicated history of ownership, but I'm not
| sure I understand why Oracle is able to block contributions to
| OpenJDK. I thought the point of OpenJDK was to be separate from
| Oracle. I'm not a Java developer, just curious how this works.
| oliwarner wrote:
| It's still their project and the Oracle Contributor Agreement
| means they get to asset joint ownership of your contributions.
|
| That's broadly the point of CLAs, but for a beefy project like
| OpenJDK with so much shared code baked deep into enterprise
| deployment, Oracle will feel it's critical they can pull freely
| given code into the depths of their closed Java builds.
|
| It's their project. It does absolutely block contributions
| (employers are unhappy sacrificing their engineering output to
| Oracle). If you don't like it, fork it.
| gf000 wrote:
| Where does oracle block contributions?
|
| This was more of an unfortunate lack of
| attention/prioritization.
|
| Don't assume malice where a simpler explanation exists.
| grishka wrote:
| OpenJDK is the "default" implementation of Java and it's
| maintained by Oracle. Beyond that, there exists at least
| OpenJ9, which is a completely independent implementation,
| maintained by Eclipse Foundation.
| themafia wrote:
| Corporations love open source when it delivers working code to
| their doorstep. They hate open source when it comes to actually
| maintaining and managing a community of developers who really
| do care about and use the core product.
|
| So they create draconian "agreements" and "codes" to tilt the
| playing field entirely in their favor. It's entirely
| antithetical to the whole idea of open source.
|
| These projects should be ruthlessly forked and all corporate
| development efforts ignored.
| M95D wrote:
| This is very common in all open source projects, not just
| Java/Oracle.
| __turbobrew__ wrote:
| I have been trying to upstream patches to kubernetes and etcd for
| about a year and ended up giving up. It is impossible to get
| someone from the project to review my PRs, and since I cannot get
| PRs under my belt I can not become a maintainer either.
|
| My suspicion is that you get ghosted if you don't have a @google
| or @redhat email address and really the only way to become a
| contributor is to be buddies with someone who works on the
| project already.
|
| I have considered going to one of the CNCF committee meetings and
| being like, hey you guys are not accepting new contributions
| which goes against your mandate. But in the end I just maintain
| local patches that don't get upstreamed which is easier.
| direwolf20 wrote:
| The CNCF may or may not take it seriously. They definitely
| won't if they don't know.
| ahmedtd wrote:
| Can you link your PRs here?
|
| Kubernetes is such a huge project that there are few reviewers
| who would feel comfortable signing off an an arbitrary PR in a
| part of the codebase they are not very familiar with.
|
| It's more like Linux, where you need to find the working group
| (Kubernetes SIG) who would be a good sponsor for a patch, and
| they can then assign a good reviewer.
|
| (This is true even if you work for Google or Red Hat)
| perfmode wrote:
| maybe you've already done this and I'm sorry if i'm telling you
| the obvious.
|
| You could analyze the repo to identify others who have modified
| the same files. and reach out to them specifically.
| Analemma_ wrote:
| I think if I were a random Google employee submitting
| Kubernetes patches at my day job-- i.e. not a project
| maintainer, but just someone in the K8s org chart-- I'd be
| kind of annoyed if I got cold-emailed asking me to help merge
| their patches. I'd probably trash that email and assume it
| was some kind of scam.
|
| I get that the current system isn't working, but I don't
| think you should just go emailing random committers, that
| seems likely to just piss people off to no benefit.
| pklausler wrote:
| Github suggests reviewers to PR authors based on who's been
| modifying nearby code recently (ok, I don't know whether
| that's a general policy, but it happens to _me_ all of the
| time). And for the past year or so I have been getting
| tagged to review more and more AI slop from newcomers to
| the project that we chose to maintain in public. I just
| immediately nope out of all reviews now if I don 't
| recognize the submitter, because I don't scale enough to be
| the only actual human involved with understanding the code
| coming at me. This sucks for the newcomers who actually
| wrote the patch themselves, but I can't always tell. Put
| some misspellings in your comments and I'm actually _more_
| likely to review it!
| socalgal2 wrote:
| I haven't seen your PRs and I don't work on those project. I
| have small projects that receive few patches.
|
| My experience of the few patches I have received though is they
| are 100% without exception, bad patches. Bad in that, without
| me putting an hour or 2 of work into them I can't just accept
| them. The most common case is no tests. The patch fixes an
| issue, but the issue exists because there was no test for the
| case the patch is fixing. So, to accept the PR, I have to
| download it and spend time writing a test.
|
| Other common experiences are bad coding practices and non-
| matching styles so I have two choices
|
| (1) spend 30-60 minutes downloading the patch, fixing these
| issues myself
|
| (2) spend 40-60 minutes adding comments to try to get the
| person who posted the PR to make their patch acceptable (40-60
| mins includes the back and forth).
|
| More often than not, (2) never gets a response. The
| contributor's POV is they provided a fix and I should be happy
| to take it as is. I get that. At a certain level they are
| correct. But, these projects are hobby projects and I have
| limited time. So I generally don't do (2) because if they
| ignore the comments then it's wasted time, and (1) has the
| hurdle that I need to take an hour out to deal with it.
| xyst wrote:
| Wouldn't it be best to ask contributor to reproduce the bug
| with a test rather than just completely ghost them?
|
| Companies such as Google have billions at their disposal yet
| still can't figure out simple project management?
|
| Google of the past is no more, unfortunately.
| pousada wrote:
| It's not worth the time. You will spend uncountable hours
| of (unpaid) extremely exhausting labour talking to people
| who only care about solving their personal super specific
| problems. This is true for 90%+, there are exceptions but
| they are exceedingly rare
|
| Trust me I tried many many times.
|
| This has nothing to do with Google being evil it's just one
| of the realities of maintaining a big open source project.
| SOLAR_FIELDS wrote:
| Your first example should be solved by the maintainers
| outlining clear contribution guidelines. It's not hard to
| point some automation at a pr and comment if someone didn't
| follow contribution guidelines.
|
| Nonmatching styles can be mostly solved with linting and
| static analysis
|
| There's no fix for bad code outside of manual review beyond
| that. But doing those things should significantly cut down on
| your noise.
| pousada wrote:
| Trust me it's not being solved by a CONTRIBUTING.md with
| guidelines.
|
| 90% of contributors won't read it at all or only some parts
| of it and ignore the rest.
|
| Most PRs you get solve some super specific individual
| problem and aren't relevant for the wider community that
| uses your OSS.
|
| It's not their fault really but most contributions are so
| bad it doesn't serve to spend any time on reviewing them
| earnestly.
|
| (Been maintaining several popular projects for the last 7
| years)
| judahmeek wrote:
| Can I get your opinion on
| https://github.com/Judahmeek/frogs as an open-source
| maintainer?
| yicmoggIrl wrote:
| > It is impossible to get someone from the project to review my
| PRs
|
| Sorry to say this, but this is natural. Writing patches is
| easy. Reviewing them is hard. Writing patches (and getting them
| accepted, merged) is rewarding and _demonstrable_ (as a form of
| achievement). Reviewing patches, educating new contributors is
| sometimes rewarding, sometimes not (it 's an investment into
| humans that sometimes pays off, sometimes doesn't), but mostly
| not a demonstrable achievement in either case. Therefore there
| is incentive to contribute, and hardly any incentive to review.
| This is why reviewers are extremely scarce in _all_ open source
| projects, and why all sustainable projects optimize for
| reviewer /maintainer satisfaction, not for contributor
| satisfaction. As an external contributor, you just don't get to
| allocate scarce resources financed by some commercial entity
| with no relation to you.
|
| If you want to become a maintainer, or at least want others to
| review your stuff, don't start by writing code. Start by
| _reading code_ , and make attempts at _reviewing_ code for
| others. Assuming you get good at it, established project
| members should start appreciating it, and might ask you to
| implement some stuff, which they could be willing to review for
| you. You first need to give the _real_ kind of effort before
| you can take it.
|
| And this is why "open development" is a total myth today.
| Resource allocation and work (chore) distribution are aspects
| of reality that completely break the wide-eyed, bushy-tailed
| "new contributors welcome" PR message. Opening up the source
| code (under whatever license) is one thing, collaborating with
| randos is an entirely different thing. Can you plan with them
| in advance? Do they adhere to your deadlines? Can you rely on
| them when things break? When there are regressions?
|
| > you get ghosted if you don't have a @google or @redhat email
| address and really the only way to become a contributor is to
| be buddies with someone who works on the project already
|
| Yes, and the way to become buddies is to help them out where
| they are hurting: in their infinite patch review backlogs. Of
| course, that means you have to invest a whole lot of seemingly
| thankless learning, for the long run's sake. You have to become
| an expert with effectively nothing to show for it in the git
| history. It's totally fair not wanting to do that. Just
| understand that a ticket that remains open indefinitely, or an
| uncalled-for contribution that never gets reviewed and merged,
| may genuinely be better for the maintainers than taking on yet
| more responsibility for your one-off code contribution.
|
| > I have considered going to one of the CNCF committee meetings
| and being like, hey you guys are not accepting new
| contributions which goes against your mandate
|
| According to the above, I bet that "mandate" is a total fake; a
| PR move only. It does not reflect the actual interests of the
| organizations with the $$$, which is why it doesn't get
| followed.
|
| You _are_ right that those orgs should at least be honest and
| own up to _NOT_ welcoming newcomers or external contributors.
| Freak_NL wrote:
| I know it is a deeply culturally ingrained idiom for Chinese to
| use in English, but the phrase "I do live in Chinese Mainland"
| sincerely irks me from someone who is attempting to claim the
| high road of having no affiliations with any sanctioned entities.
|
| The phrase "Chinese Mainland" when used in English comes loaded
| with the suggestion that Taiwan is rightfully part of China -- it
| is an unavoidable implication. If you believe that China should
| annex Taiwan by any effective means, by all means, use that term.
| But if you want to steer clear of imperialist politics -- or just
| leave that out of your communications -- just use "China" in
| English for the big country run by Xi Jinping.
|
| And no, saying "I do live in Chinese Mainland" is not just a way
| of saying "Oh, I don't live on Macau or in Hong Kong".
| arglebarnacle wrote:
| Interesting, when I've come across this before I have always
| interpreted it as "not from Hong Kong", especially in a context
| like this where it's raised in the context of engaging with a
| western counterpart's potential suspicion.
|
| It's been my experience that westerners (I am a westerner) do
| have different assumptions about "mainland" Chinese people than
| people from Hong Kong who are assumed to be more cosmopolitan,
| "westernized", or even "politically neutral" from a western
| liberal capitalist perspective, so it seems reasonable to point
| it out in this context.
| amluto wrote:
| > The phrase "Chinese Mainland" when used in English comes
| loaded with the suggestion that Taiwan is rightfully part of
| China
|
| For better or for worse, many people on both sides of the
| strait have used language along these lines that suggests that
| Taiwan is part of China for decades and probably even since a
| bit before 1949 (I was not alive at the time). I think that, at
| this point, the term "mainland China" is just the default.
|
| That being said, a person from China could just say they're
| from China and no one would be confused. This is in contrast to
| someone saying they're Chinese, which can be ambiguous.
| verall wrote:
| > The phrase "Chinese Mainland" when used in English comes
| loaded with the suggestion that Taiwan is rightfully part of
| China -- it is an unavoidable implication.
|
| I'm really curious - what people did you get this idea from?
| I've never heard this before. I have heard "mainland China" to
| mean, specifically, "China, not Hong Kong or Macau", from:
|
| - Taiwanese people
|
| - Hong Kong people
|
| - Mainland Chinese people
|
| - Taiwanese-americans
|
| - Chinese-americans (immigrated from the mainland)
|
| It's just mainland China (Da Lu ). I have never met Chinese or
| Taiwanese people who feel this is a politically loaded term.
| NooneAtAll3 wrote:
| I always parsed it the other way... "Mainland" suggests there's
| some other part, while China means unified
| gavinray wrote:
| I signed the OCA in 2021 as part of some contributions to
| GraalVM.
|
| The process was much more involved than anything I'd previously
| signed, and it was slow, but in my case eventually got approved.
|
| It mostly involved some emails with an actual human and PDF's to
| be docu-signed.
| nubinetwork wrote:
| Despite their OSS contributions, and the fact that they have
| their own Linux distro, oracle is one of the worst companies to
| deal with in terms of OSS. Very NIH syndrome, very gatekeep-y. I
| refuse to use grub because I know I'll never get bugs fixed since
| oracle claims ownership of the repo there as well.
| throwaway290 wrote:
| why do they waste all that ai writing new patches instead of
| helping them upstream existing patches?
| xyst wrote:
| I am not surprised. Oracle acquiring Sun Microsystems has been
| the death kneel of open source Java ecosystem.
|
| Never forget: One Rich Asshole Called Larry Ellison still runs
| this company.
| _benj wrote:
| Would there be a difference in contributing to OpenJDK vs to,
| say, Temurin or Zulu Java? How separated are those Java JDKs
| really from OpenJDK?
| embedding-shape wrote:
| Temurin and others are "distributions" of OpenJDK, basically
| their compilation results of it, not their own codebase.
| They're not "forks" in terms of source code, but they have
| patches, build systems, QA, and everything else around it that
| they apply, then offer you their version of it.
| OpenJDK: where Java is developed Temurin / Zulu: where
| OpenJDK is built, tested, packaged, and supported
| Phelinofist wrote:
| In a response Dalibor Topic claims that he rejected some of his
| submission have been rejected. So one of them is lying?
| markus_zhang wrote:
| Judging from the whole thread, might just be some
| misunderstanding of the workflow?
___________________________________________________________________
(page generated 2026-01-31 23:00 UTC)