Changes to 8u and 11u process

[Peter Levart]

Hi,

On 8/8/19 12:34 PM, Lindenmaier, Goetz wrote:
> Hi Aleksey,
>
>> On 8/6/19 3:46 PM, Andrew Haley wrote:
>>> Backports which have already been approved by Oracle for their
>>> proprietary fork will no longer need approval for 8u- and 11u-open.
>>> There are two reasons for this. Firstly, it's safe to assume that
>>> Oracle have done their due diligence with regard to suitability.
>>> Secondly, it's a waste of effort on the part of the maintainer.
>> I vehemently oppose this rule.
>>
>> First, this dismantles the consistency of the process ("every change should be
>> approved, here is the
>> checklist [1]") for the sake of less maintainer work (which can be alleviate by
>> assigning more
>> maintainers, as we did with Christoph). Having a single checklist for everything
>> is simpler to
>> remember, simpler to act upon, and it provides less cognitive load. We need to
>> continue doing the
>> same thing on all paths, and if on some of those paths it would reduce to
>> mechanical rubber-stamping
>> work, so be it. It is the same as with code reviews in trivial patches: we do not
>> circumvent the
>> review process by telling "trivial patches do not need review", we just say
>> "trivial patches enjoy
>> more mechanical rubber-stamping approach".
> You can as well argue that the need to get an approval for a change
> increases the work and thus the possibility to make errors.
> You can not expect the maintainer to approve changes on a daily
> basis. Thus, you get quite some delays with the work on the changes.
> You downport them, test them, ask for approval, and once you get
> it you need to rebase the change and retest them. This rebasing and retesting
> is overhead that could be avoided.  Also, personally, I don't like working
> on too much changes in parallel. If getting the approval takes a week,
> this limits efficiency.  From my work on our internal JVMs, I know that
> you can move quite a lot of changes on a single day without breaking
> anything.

What about allowing for such changes to be pushed "optimistically" 
immediately after posting the request for approval (jdk11u-fix-request). 
If such change gets rejected, it would be backed-out and then possibly 
further worked on as a normal change that needs to be pre-approved 
before being pushed again.

Regards, Peter