Changes to 8u and 11u process

[Andrew John Hughes]

On 08/08/2019 11:34, 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.
> 

It shouldn't take a week. That's a case for adding more maintainers to
share the workload, not a reason to abandon the process altogether. I
think ideally we should have at least three on each project, as
currently a maintainer wanting a patch approved has to rely on a single
individual for that approval.

Working on a public project is fundamentally different to an internal
project, as the impact of any change is much wider and others have to
integrate your changes into their workflow (including those who may
interact on the mailing lists little, if at all). I would rather things
were done slowly and carefully than to wake up to a dozen new changes
every morning.
-- 
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