RFR: Added section on maintainer-pain [v2]

[Jesper Wilhelmsson]

On Tue, 17 Nov 2020 04:43:06 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>>> @JesperIRL , looks good to me in general. however, I'm not sure that every occurrence of `maintainer-pain` should be a reference, usually, it's enough to have just 1st appearance as a reference.
>> 
>> Currently all JBS labels in the Guide are linked to a description of the label. I see your point, it's unnecessary to link every single occurrence in such a short section, but if you don't mind terribly I'd like to maintain the invariant that every JBS label mentioned is linked ot the description.
>> 
>> Do you find it extremely ugly with all the links?
>
>> > @JesperIRL , looks good to me in general. however, I'm not sure that every occurrence of `maintainer-pain` should be a reference, usually, it's enough to have just 1st appearance as a reference.
>> 
>> Currently all JBS labels in the Guide are linked to a description of the label. I see your point, it's unnecessary to link every single occurrence in such a short section, but if you don't mind terribly I'd like to maintain the invariant that every JBS label mentioned is linked ot the description.
>> 
>> Do you find it extremely ugly with all the links?
> 
> I haven't seen it rendered, so for the present, I don't find it ugly at all ;)

These comments came to me through other channels. Saving here for tracking purposes.

> Maybe a better heading too as “Handling Maintainer Pain” will be alien to most people.

Renamed it to "Tracking noisy issues (maintainer-pain)" 

> I think the phrase “engineering time” should be dropped as I don’t think it make sense in the context of OpenJDK.

Right. Fixed.

> Also I thought we decided early on to talk about excluding tests, not “ProblemListing”.

I hear different opinions on this. I have removed all instances of ProblemListing in this section, but the section about excluding tests is still using this term.

> It might be useful to outline a few board examples of issues to explain what this section is about. I think it’s about frequent failures, maybe on a specific platform, maybe specific to one vendor’s test infrastructure. It might is some underlying bug that causes several tests to fail intermittently. Maybe it’s a change causes a test failure in a faraway place and the failure isn’t acted on quickly.  So more text to explain what it is about would be useful.

I broke the text into separate examples and added the cases you brought up as well.

> I think the main point you want to get across is you want to drop test failures that would waste time investigating because it’s already tracked.

That's one use case but there are other. For instance a bug that causes test failures all over the place - even if everyone know what but it is and no time is spent investigating the issue the failures are clearly a pain to everyone.

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

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