How to handle future backports from JDK 10 into JDK 9? (original) (raw)

Stuart Marks stuart.marks at oracle.com
Sat Feb 18 02:23:40 UTC 2017

On 2/17/17 10:20 AM, Joseph D. Darcy wrote:

The designers of jcheck made an architectural decision to not have jcheck depend on or use the bug database.

Without revisiting that design decision, a wrapper script of some sort is a way the check in question could be implemented today.

It's perhaps unfortunate that jcheck doesn't depend on the bug database, but I agree that we don't want to revisit this particular design decision at this point. (I suspect that if jcheck were to depend on the bug database, we'd be complaining continually about all the problems that this would have caused.)

It remains true that there are several phenomena that can occur with the bug IDs in the changeset comments:

  1. using the same bug ID for logically different changesets;

  2. using the same bug ID for logically equivalent changesets introduced on a different branch;

  3. typo in a bug ID resulting in a comment referring to a nonexistent bug;

  4. typo in a bug ID resulting in a comment referring to a valid, but incorrect bug; and

  5. use of a backport bug ID instead of the main bug ID.

Cases 1, 3, 4, and 5 are considered to be errors, but the duplicate checking only prevents case 1. The other kinds of errors occur occasionally, and it's annoying when they do occur, but it's not a disaster.

Meanwhile, duplicate checking gets in the way of case 2, the standard workflow for the sustaining releases, and thus it's been disabled for those releases for quite some time. It's also getting in the way of the proposed JDK 9 => JDK 10 workflow (pulling changes from the old release into the new release). Everybody on the planet except OpenJDK has been doing this for years. Its benefits outweigh the minor benefit of preventing duplicates.

It would be helpful to think about approaches to prevent these kinds of errors. If jcheck isn't doing to depend on the bug database, perhaps an adjoint tool could be developed that does.

I'd further suggest that the changeset comments be part of the code review, and that reviewers check this. I notice that many people post reviews of uncommitted changes. Perhaps we will have to change this practice.

s'marks

In my estimation, using back port bug ids for pushes would be more prone to errors/typos than continuing the long-standing policy of using the main bug id in such cases. That wasn't the suggestion. The suggestion was to create a new bug eg "Backport 8134567 to JDK 9" and use that bugid for the "backport" instead of creating an actual backport-issue using the original main bug id. That approach, while workable, seems to me to work across purposes with the bug tracking system. The most natural way to represent a backport is a backport issue. -Joe

More information about the jdk10-dev mailing list