2017-05-31 13:50 GMT+02:00 John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>: > On Wed, May 31, 2017 at 01:33:13PM +0200, Mario Torre wrote: >> > Ok, so I signed the OCA and sent in three patches to address build >> > issues on Linux/sparcv9. Those patches were rejected with the argument >> > that no one can test the code, even though Oracle themselves >> > officially support Oracle Linux on SPARC [1]. >> >> Do you have a link to this discussion? > >> http://mail.openjdk.java.net/pipermail/build-dev/2017-May/019301.html >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-May/026984.html > >> > So, how can I get those fixes in? >> >> As Dalibor said, this kind of patches tend to be very invasive, and as >> a first contribution especially the entry barrier is quite high. You >> may have better luck in trying to merge them into a separate Project >> repository or start with a smaller set of changes. > > Those patches aren't invasive. One fixes a filename, one adds a > missing #include and the third one adds a missing variable. All within > the linux_sparc folder.
I can't check the patches in detail now, but I see that the discussion on those threads doesn't go much on the technical side but rather focus on whether Oracle should support or not their own products :) I think David's reply was highlighting the actual points instead: * The status of linux-sparc as a port in OpenJDK 9 (or 8u) is unclear * There is no way you will get them JDK 9 at this stage, this work needs to be done on 10 * Hotspot group leads should have a say on this I think it makes sense to seek the hotspot leads approval for that work before anything else. >> In the meantime perhaps I would suggest to get in touch with the >> distro-pkg-dev people since they may help you, even if this is not >> Linux specific. > > I am one of the maintainers of the Debian/sparc64 port and we have the > possibility to add distro-specific patches. However, I don't want to > carry these patches around forever but rather get them merged upstream > and make them available to all downstreams, not just Debian. > The way we have done that in the past is exactly this, slowly merge upstream all the downstream specific changes, it's a process that takes a lot of time, especially at the beginning when you need to build trust and experience with the upstream developers. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/
