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.
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)
> 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?
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...
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.
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.
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.
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.
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".
> 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 (大陆）. I have never met Chinese or Taiwanese people who feel this is a politically loaded term.
> 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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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)
The CNCF may or may not take it seriously. They definitely won't if they don't know.
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.
Anyone who has been a freelancer negotiating a contract with a big company feels this sort of thing in their bones.
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...
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.
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.
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.
Where does oracle block contributions?
This was more of an unfortunate lack of attention/prioritization.
Don't assume malice where a simpler explanation exists.
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.
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.
Absolutely. I look at the commit and PR history. Are the maintainers responsive and welcoming?
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".
> 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 (大陆）. I have never met Chinese or Taiwanese people who feel this is a politically loaded term.
> 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.
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.
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.
[delayed]
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.
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.
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
I agree but I would also never contribute to a project with a CLA in the first place.
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
Or a ton of "personalized agents" will start bugging upstream to complain about suspected issues with all those forks all the time...
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.
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.
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.
Given they have one to fix usage of llvm-config, I assume clang is also supported or being worked on.
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.
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.
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
Shouldn't small trivial changes be easier to review (and thus maybe even have higher prio)?
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.
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.
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.
The d suffix makes it not compile under clang. The PRs seem like mostly small changes that are clear improvements.
The correct quote is: "Remove invalid 'd' suffix for double literals".