RFR: Filing bug, ProblemListing, Backing out [v2]

[Jesper Wilhelmsson]

On Mon, 6 Jul 2020 20:00:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed comments from review
>
> src/next.md line 73:
> 
>> 72: In this example, `MyTest.java` is ProblemListed on windows, tracked by bug `JDK-4711`.
>> 73:
>> 74: Currently there's [no support for multiple lines for the same
>> test](https://bugs.openjdk.java.net/browse/CODETOOLS-7902481). For this reason it's important to always make sure
>> there's no existing entry for the test before adding a new one, as multiple entries might lead to unexpected results,
>> e.g.
> 
> Not sure where in this review to insert this but there is a sensible policy that you should make sure the bug report is
> open. If you are submitting it that is easy to ensure but there have been cases where bugs are closed (without
> necessarily being fixed) and the issue remains PL'd. A legitimate case where this occurs if a bug is fixed in one line
> of development but the fix is not (yet:?) backported and I'm not sure how the "sensible policy" accounts for that.

This is a very good point. I'm not sure how to express it though since this is meant to be a document for everyone, not
only Oracle developers.

I'm not sure what you mean with regards to the backport. If a fix is made in mainline it's removed from the ProblemList
in mainline. The backport should remove it from the ProblemList in the update release once it's pushed there. The one
thing that could be problematic is the `problemlist` label since that is only supposed to be on the main bug. But on
the other hand I don't think there is any automation that looks at the ProblemLists in the update trains so having the
label tied to the mainline issue won't be a problem in practice I think.

> src/next.md line 147:
> 
>> 146:
>> 147: If a change cause a regression that can't be fixed within reasonable time the best way to handle the regression
>> can be to back out the change. Backing out means that the inverse (anti-delta) of the change is pushed to effectively
>> undo the change in the repository. There are two parts to this task, how to do the bookkeeping in JBS, and how to do
>> the actual backout in mercurial. 148:
> 
> cause -> causes

Fixed.

-------------

PR: https://git.openjdk.java.net/guide/pull/21