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

Patch content and technical value

• Some commenters initially dismissed the linked patches as “noise,” but others point out they include real fixes:
  • Removing a non‑standard d suffix on double literals that fails under clang and is not permitted by the C++ standard.
  • Fixes related to llvm-config implying at least partial intent to support non‑GCC toolchains.
• Debate over whether OpenJDK is effectively “GNU C++” vs standard C++: if portability beyond GCC is intended, such non‑standard constructs are seen as legitimate bugs to fix.

Trivial patches and contributor onboarding

• Many see these as ideal first contributions: small, focused, easy to review, and helpful for learning the process.
• Others argue that for very large, critical projects (OpenJDK, Linux, Kubernetes) even trivial patches impose non‑trivial review, testing, and process overhead, and can distract scarce maintainers.
• Several people note that trivial edits may look like random linting unless clearly grouped and motivated (e.g., “clang portability”).

Oracle, OpenJDK, and contributor agreements

• The thread centers on frustration with the Oracle Contributor Agreement (OCA) and slow, confusing handling of paperwork.
• Some view this as Oracle “gatekeeping” a supposedly community project; others say it’s just bureaucracy and legal risk management.
• A later reply on the mailing list from an OpenJDK maintainer says some submissions were explicitly rejected and that OCA processing issues caused confusion; the original author then apologizes, suggesting miscommunication rather than deliberate stonewalling.
• Strong negative sentiment toward CLAs and corporate control appears, but others stress: open source licenses don’t obligate upstream to accept patches.

Broader OSS maintenance and review problems

• Multiple commenters report similar experiences with Kubernetes, etcd, Go, and other big projects: PRs languish without review unless you’re already an insider.
• Maintainers describe a deluge of low‑quality or highly narrow patches, lack of tests, and style mismatches; reviewing and mentoring is time‑consuming, often unrewarded work.
• There’s discussion of how scarcity of reviewers drives projects to optimize for maintainer convenience, not contributor satisfaction.

Philosophy and future directions

• Older contributors recall when “open source” meant “you can read and fork the code,” not “you must review my changes quickly.”
• Others counter that, since critical infrastructure now depends on these projects, there’s a broader responsibility to run them as genuine commons, not just corporate assets.
• Some speculate AI may make personal forks more common, reducing reliance on upstream—but others worry about AI‑generated low‑quality PR floods making review even harder.