Changes to 8u and 11u process
shade at redhat.com
Thu Aug 8 11:26:47 UTC 2019
On 8/8/19 12:34 PM, Lindenmaier, Goetz wrote:
> 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.
Hm, I reject the premise that more work means more errors, especially when "work" is (re)testing,
reviews, checks, approvals.
> 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
Yes, I understand that is more overhead. That is a feature, not a bug though: the fact that
maintainers have to ack the pushes makes them responsible gatekeepers. So, they can actually control
what goes in, when it does, how much due diligence is done for it (testing, related/follow-up
fixes), etc. It is my hard opinion that maintainers have to "co-own" every push that happens, by the
applying approvals/rejects unconditionally.
I am also doing lots of backports, and yes, my patch queue is usually full with simple patches. At
the same time, I do believe waiting for someone responsible to cross-check my work, no matter how
trivial it looks to me, is a major process feature. Granted, the larger gap between fix-request and
the subsequent approval does make it a bit harder. I believe this would be improved by having more
maintainers, like adding Christoph. I do not see the reason to both add maintainers and relax the
requirements at the same time.
> Why should we reject changes to a platform supported by Oracle but not
> by OpenJDK? Has there ever been a change downported by Oracle that
> was not taken into OpenJDK 11?
Not yet, but it does not mean there would not be. Process planning should see and plan for the
exceptional possibilities before those exceptions arise. I do not also believe Oracle should be
treated preferentially here. The changes Oracle backports should be scrutinized as well, and maybe
rejected when they do not hold to the scrutiny. The fact they mostly do today does not mean it would
be the same tomorrow. It does give maintainers themselves some adjustments to their perception of
risk/benefit when approving/rejecting those backports, but that's the decision the maintainer should
make, not everyone with push privileges.
> And if the two projects OpenJDK 11 and OracleJDK 11 would diverge so
> that this happens, we still could change the policy again.
Changing policy again would be even more confusing. Human-facing policies are not computer code,
there is so much hysteresis between changing the policy and its proliferation. From my observations
how people learn and apply the rules, having the overheady but steady ruleset is much, much, much
better than having the "optimized" branchy ruleset. Let people use the single checklist they learned
already, and fly with that.
> But people being less involved in
> the updates project probably come up with changes of their own for which
> the established process holds and thus never get in touch with this
> "shortcut rule".
I suspect what would really happen is this: non-involved people would look into JIRA, discover
issues that are pushed without approval (oblivious of the shortcut rule), assume no approval is
needed for their issue at hand, push their non-Oracle-existing backport without approvals. That's
what you would get for having exceptions in the ruleset. Please do not shortcut.
More information about the jdk8u-dev