First time contributor experience

[Michael Paus]

Hi,
everybody can (and should) file bugs here: 
https://bugs.java.com/bugdatabase/
Have you tried that already?
Michael

Am 17.11.20 um 23:32 schrieb Marius Volkhart:
> Hi Magnus,
>
> I haven't been able to get any traction with my Pull Request. I've sent 2
> mails to core-libs-dev mailing list.
>
> I believe I've found a bug in the javax.xml module. An issue for this
> behavior does not exist in the bug tracker, and I do not have a OpenJDK
> account so I can't open an issue. The PR includes a fix with a test. What's
> the right course of action for me here?
>
> --
> Cheers,
> Marius Volkhart
>
>
>
> On Thu, Nov 12, 2020 at 1:33 AM Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
>> On 2020-11-07 19:54, Marius Volkhart wrote:
>>> Hello,
>>>
>>> I've been working on making my first JDK contribution, and thought I'd
>>> provide some feedback on the process.
>> Hello Marius,
>>
>> Thank you for reporting your experiences, in such a constructive tone.
>> This is all very new to us, and there are certainly road bumps that need
>> to be flattened. Some may be easy to fix, and other may be harder. But
>> getting feedback about what's the pain points of a new contributor
>> certainly helps us understand where there are work left to do.
>>
>> /Magnus
>>> My motivation for contributing is that I found 2 bugs in javax.xml.
>>>
>>> My first thought was to 1. see if there is an existing bug, and 2. if
>> not,
>>> file a bug. As it turns out, I can't file a bug at bugs.openjdk.java.net
>> .
>>> This was a pretty big demotivator, and caused me to stop JDK work for the
>>> day. In my previous experiences with open source projects, be it Apache,
>>> OpenJ9, or other projects on GitHub, filing a bug was very easy.
>>>
>>> Getting the source code was really easy thanks to it being on Github now!
>>> This was great. Unfortunately, I found myself running up a steep cliff
>>> pretty quickly thereafter.
>>>
>>> The CONTRIBUTING.md indirection led me to the OCA. Again, I'm used to
>>> easier CA processes, typically something like https://cla-assistant.io/
>> but
>>> it was alright. One thing that was not clear from the contributing page
>> is
>>> that I need to specify my GitHub username in the Username field of the
>> OCA.
>>> The OCA process was really fast, and Dalibor was very prompt.
>>>
>>> Now, given that I had something I wanted to work on, and it was a minor
>>> change most likely best discussed via code, and I already figured out
>>> where/what the bug was, I figured I'd make a PR next. The contributing
>>> guide doesn't know what PRs are yet, and I don't have a sponsor, so I
>>> figured that from here on out, I was on my own.
>>>
>>> Next I tried to get working with the code, and quickly realized that I
>> had
>>> absolutely no idea of how to get started with this in an IDE (Intellij in
>>> my case). I'm used to having a Maven or Gradle project, or even something
>>> like Bazel that lets me generate IDE project files. A guide on how to
>> edit
>>> the Java parts of the JDK in the popular IDEs would be immensely helpful.
>>>
>>> Fortunately my first bug is an easy 1 line change, and doesn't need any
>>> imports or formatting or whatever. I chose to hold off with writing a
>> unit
>>> test because I don't even know how to run it yet.
>>>
>>> So now I figured I'd try the build instructions linked in the README. The
>>> TL;DR is exactly what I wanted, and all went well until I got to running
>>> the tier 1 tests. That step fails because something called jtreg is
>>> missing. I tried to install via my package manager (homebrew, I'm on a
>> Mac)
>>> but jtreg isn't on there. I found the GitHub repo for it, but there are
>> no
>>> prebuilt artifacts on GitHub, and building jtreg wasn't something I
>> wanted
>>> to delve into. Ant & talk of JDK 7. (Several days later I found
>>>
>> https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/lastSuccessfulBuild/artifact
>>> but I don't know why there are 2 versions there.)
>>>
>>> In the course of trying to figure out what jtreg is, I learned that
>> TestNG
>>> is used, so I wrote my unit test in an out of band Gradle project and
>>> copy/pasted the file into the JDK tree.
>>>
>>> I decided to just make the change, push it, and have the GitHub Workflow
>>> build and run the tests. The Workflow is great, and it was pretty easy to
>>> get my fork to run the tests. How to get your fork to run the tests is
>>> probably something that should be explained or called out in
>>> CONTRIBUTING.md. I now wanted to see if my tests got picked up by the
>> tool
>>> and passed. I downloaded the test results ZIP, but am completely
>>> overwhelmed by the contents. Is my test in testresults_part1?
>> testsupport?
>>> debug_testresults_common? I couldn't find it.
>>>
>>> I gave up at this point, and just pushed the change, hoping that someone
>>> who knows how this all works can tell me exactly what changes to make, or
>>> will pick up the patch and do what needs to be done.
>>>
>>> The biggest hurdles for me for working on the code are 1. Getting the
>> code
>>> into my IDE, and 2. Acquiring and working with jtreg. The biggest hurdle
>> to
>>> contributing is the inability to file bugs.
>>>
>>> I hope this helps in improving the contributor experience.
>>>
>>> --
>>> Cheers,
>>> Marius Volkhart
>>