"Giving up upstream-ing my patches & feel free to pick them up"

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 an hour ago \| parent [-]
		Anyone who has been a freelancer negotiating a contract with a big company feels this sort of thing in their bones.

▲

beart 31 minutes ago | parent | prev | next [-]

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.

▲

freedomben 2 hours ago | parent | prev | next [-]

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.

▲

Cpoll an hour ago | parent | next [-]

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.

▲

aeurielesn an hour ago | parent | prev [-]

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 an hour ago \| parent [-]
		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

▲

voakbasda 2 hours ago | parent | prev | next [-]

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 27 minutes ago \| parent [-]
		Absolutely. I look at the commit and PR history. Are the maintainers responsive and welcoming?

▲

pjm331 40 minutes ago | parent | prev | next [-]

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 21 minutes ago \| parent [-]
		Or a ton of "personalized agents" will start bugging upstream to complain about suspected issues with all those forks all the time...

▲

dwroberts 3 hours ago | parent | prev [-]

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 2 hours ago | parent | next [-]

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 2 hours ago | parent | next [-]

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 an hour ago \| parent [-]
		Given they have one to fix usage of llvm-config, I assume clang is also supported or being worked on.

▲

dwroberts 2 hours ago | parent | prev [-]

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 2 hours ago \| parent [-]
		Shouldn't small trivial changes be easier to review (and thus maybe even have higher prio)?

▲

perryprog 2 hours ago | parent | prev | next [-]

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 2 hours ago \| parent [-]
		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.

▲

thethirdone 2 hours ago | parent | prev | next [-]

The d suffix makes it not compile under clang. The PRs seem like mostly small changes that are clear improvements.

▲

ablob 2 hours ago | parent | prev [-]

The correct quote is: "Remove invalid 'd' suffix for double literals".