RFR (XS) 8219691: method summary table head should be enclosed in <thead>

[Derek Thomson]

Perfect, thanks!

On Tue, Mar 12, 2019 at 9:11 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> The change is just busy-work for everyone, so I'll take care of it.
>
> -- Jon
> On 3/11/19 5:11 PM, Derek Thomson wrote:
>
> Thanks! I'm actually working on a webrev including that change now, but I
> probably won't get JC to upload it until tomorrow at this point. I'm happy
> for you to fix that, if it's faster for you.
>
> On Mon, Mar 11, 2019 at 5:09 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> OK, this looks good, and can sponsor this change,
>>
>> I'll take care of the addContent for you if you like.
>>
>> -- Jon
>>
>> On 3/11/19 2:48 PM, Derek Thomson wrote:
>>
>> Jonathan - I have an update of this fix in
>> http://cr.openjdk.java.net/~jcbeyler/8219691/webrev.01/
>>
>> I didn't add a new test as the coverage was already good, lots of failure
>> at least, and equal to what was tested for the previous behaviour.
>> 
>> The tests are fast and I do appreciate that - I can run them
>> semi-continuously. They also didn't suffer from really silly brittleness
>> (because they don't diff entire files I think) and are pretty clear. I find
>> the output a little confusing, there are a couple of minor tweaks I could
>> make that will help I think. Would help *me* at least - stay tuned.
>>
>>
>> On Thu, Mar 7, 2019 at 2:30 PM Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>> OK, thanks for the update.  The comment/behavior is noted, though. I've
>>> tried hard to make it easier to debug test failures, and first impressions
>>> from a "newcomer" are always valuable.
>>>
>>> For my part, I find that running all javadoc tests is "fairly fast" and
>>> running any one test is "very fast", so it becomes practical to work
>>> through the first few reported issues in any test failure, and rerun.
>>>
>>> -- Jon
>>>
>>>
>>> On 3/7/19 2:23 PM, Derek Thomson wrote:
>>>
>>> Thanks Jonathan. This might have been a false alarm - I'm finding that
>>> as I fix the errors caused by my change the other failures in the same test
>>> seem to just disappear, even though they were (to my eye) matching against
>>> unrelated sections of the HTML. Let me finish up, and I bet it'll be fine
>>> after all.
>>>
>>> If any are left broken after that, I'll raise them here.
>>>
>>>
>>>
>>> On Thu, Mar 7, 2019 at 2:18 PM Jonathan Gibbons <
>>> jonathan.gibbons at oracle.com> wrote:
>>>
>>>>
>>>> On 3/7/19 2:01 PM, Jonathan Gibbons wrote:
>>>> >
>>>> >
>>>> > If you are seeing tests that fail, I suggest you discuss them here
>>>> > first, before embarking on any additional campaign to get them
>>>> > working. Given the number of CI systems building and testing OpenJDK
>>>> > on all platforms, I would be very surprised to hear of tests failing
>>>> > in an unmodified repo.
>>>> >
>>>> ... I should be more specific:   if you are seeing tests failing for
>>>> reasons unrelated to your change ....
>>>>
>>>> -- Jon
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20190312/6a9df8d3/attachment-0001.html>