Life of a Bug - Next Generation

[Jesper Wilhelmsson]

Hi Eric,

It's unclear to me exactly what you want clarified, but I'll give it a try. Please be more specific in your questions if you don't get the answer you are looking for.

> As I try to better understand the openjdk development process I stumble
> across a very helpful informative (older) blog entry.
> 
> https://blogs.oracle.com/java/a-bugs-life:-java-7-updates

This is a very old post but some of it is still relevant. The process of bug triage, a bug's priority, and a bug's state hasn't changed. The WebBugs team still triage bugs filed through the bug report tool (https://bugreport.java.com/ <https://bugreport.java.com/>).

The blog post recommends that someone new to the project should pick a p4 or p5 bug to get started. While choosing a bug with lower priority may be a good idea as there is less urgency around fixing it, there is no correlation between a bug's priority and how difficult it is to fix it. A p5 bug can be just as hard or even harder to fix (especially if it's intermittent) as a p1. In many cases it's actually quite the opposite - a crash that happens often (like during JVM startup) or a change that breaks the build is often quite easy to fix but would clearly be a p1 bug.

> With the migration to git and it’s applicable features, and the build
> changes can anyone clarify some more on this?
> 
> If this has been documented already elsewhere (i.e.
> https://openjdk.java.net/guide/) I apologize up front but still was
> interested in how things have further changed

The Developers' Guide is where you would ideally find these answers, yes. The parts that explains how to work with git hasn't been completed yet unfortunately. Many other parts of the development process is described there though.

> I assume the changes mainly involve things like:
> - Code migration from Mercurial to github for configuration control

The move to GitHub means that we now use git for revision control of the source code instead of mercurial and that the source mirrors are hosted by GitHub instead of Oracle. That's the main change, and depending on how you choose to work it could even be the only change.

> - Bug Tracking (may have some different methods in tracking)

No changes has been made to the bug database or the bug report tool.

> - Branch/release management (i.e. git commit/branches/master vs
> development, and build/release cadence, etc.) in git

No changes has been made to branch/release management (yet). The release cadence is unrelated to what tools we use for development.

> - Review (leveraging “Pull Requests” in git including applicable flags
> involved in PRs [like the OCA, milestones, review requests, etc.)

The move to GitHub enabled the use of their infrastructure for code review. This is really nice and a lot of OpenJDK developers use it frequently. There is no requirement to use it though. You can still review all changes using the old webrev format and the main channel for ALL review comments and discussions around a bug is still the mailing list. The Skara tooling developed to accommodate the move to git simplifies and automates a lot, for instance the OCA check, but process wise nothing has changed in this area.

Hth,
/Jesper

> 
> Eric Bresie
> ebresie at gmail.com
> --
> Eric Bresie
> ebresie at gmail.com