First time contributor experience

Tue Nov 17 23:03:50 UTC 2020

I had not found that before, thanks! I don't believe any of the
contributing docs that I read directed to that page, and the bug database
JIRA homepage doesn't have a link to it either.

--
Cheers,
Marius Volkhart

On Tue, Nov 17, 2020 at 11:47 PM Michael Paus <mp at jugs.org> wrote:

> 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
> >>
>
>