How to handle future backports from JDK 10 into JDK 9?

[Stuart Marks]

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