8u232 Rampdown: Bug Triage

[Andrew John Hughes]

On 03/09/2019 10:53, Andrew Haley wrote:

snip...

> 
>> My current thinking is:
>>
>> * Suitable for rampdown
>>   - #1, #7, #8, #13, #15, #16, #18
>>
>> * Defer to 8u242
>>   - Access bridge patches (#2, #11)
>>   - Apache Santuario work (#3, #4, #6, #10, #14, #17)
>>   - AWT bugs (#5, #9)
>>   - Deadlock bug (#12)

So, based on your comments, I would update this to:

* Suitable for rampdown
   - #13, #15, #16, #18

* Defer to 8u242
   - Access bridge patches (#2, #11)
   - Apache Santuario work (#3, #4, #6, #10, #14, #17)
   - AWT bugs (#5, #9)
   - Deadlock bug (#12)
   - Gtk+ default switch (#1)
   - Javadoc correction (#7)
   - "file" URLs (#8)

I agree with you about #1, in retrospect. I guess I was just a little
disappointed that it seemed to have been missed, when it could have been
an easy backport early in the cycle.

I'm not sure why I added #7 to the rampdown list when I also said we
should wait for the online version, so thanks for catching that.

As #8 depends on another bug (backporting ClassFileInstaller changes),
I'm now tending towards punting that to 8u242 as well, but I'm open to
someone making a case for inclusion if the bug warrants it.

Of the remaining four marked for rampdown, three are pretty much done
and would have been pushed if not for some minor issues found in the
review process. The only one that actually needs backporting from
scratch is the tzdata one, where there's a precedent for that coming in
late with the security changes. I'll get onto that for 8u & 11u as soon
as rampdown of 8u is completed.

>>
>> Other bugs may be considered during rampdown, but they should be
>> regression fixes or minor bugs / test issues. Feature work should now be
>> focused on 8u242.
> 
> I agree.
> 
>> I think things look better than the last cycle, but we are still seeing
>> too many patches towards the end of the development period. If you want
>> to target something for 8u242, now is the time to start working on it.
>> For 8u232, the primary focus should be testing to make sure there are no
>> major regressions.
> 
> I agree with that too.
> 
> Thank you for this very clear summary. It must have been a significant
> effort.
> 

Thanks. It did take longer than I initially expected, but it was also
helpful to me in organising everything.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew