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

[David Holmes]

Hi Stuart,

On 18/02/2017 12:23 PM, Stuart Marks wrote:
>
>
> 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.)

But we will be in exactly the same boat if the bug database access is in 
the wrappers we use! The person submitting won't know where in the chain 
the bug database occurs.

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

True.

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

Sorry have to correct you there. It is the flow from JDK 10 back to JDK 
9 that has the problem, the other way is working fine AFAIK. Second 
point is that the "standard workflow" disables duplicate checking in the 
update-release forest _not_ the main forest.

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

I find it painful to have to do commits, rollbacks and re-commits to 
allow a committed changeset to be used for review. Many others use 
"committed" but fake changesets via MQ etc so validating those at review 
time would be pointless. Plus we don't have Reviewers before the review 
- I guess we can use duke as a substitute - but then we might forget to 
update with the real reviewers. :) So, sorry but I don't really see this 
as a viable approach. Too much pain to prevent rare errors IMHO.

Cheers,
David

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