Changes to 8u and 11u process

[Andrew Haley]

On 8/7/19 4:36 AM, Andrew John Hughes wrote:
> On 06/08/2019 14:46, Andrew Haley wrote:
>> We've been running 8u and 11u for two quarters now, and it's time to
>> adjust our processes.
> 
>> 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.
>>
>> Backports of fixes to tests no longer need to be approved, but they
>> should still be reviewed if there are any changes.
> 
> I strongly oppose this, for many of the reasons Aleksey has already
> outlined.

OK. As long as people are actually gaining some value from the
process, I'm happy for it to continue.

>> We will use the CSR process, with the help of the CSR team, for any
>> backports of patches which required CSRs in mainline. Hopefully this
>> will be rare, and the CSR team will process review requests promptly.
>>
>> Finally, more of a recommendation.
>>
>> Rule #0: Do no harm.
>>
>> I know of no very strong reason why 8u- and 11u-open should in general
>> have much more churn than the corresponding closed projects. If they
>> have, there is a serious risk that they will be less stable. We must
>> avoid, above all else, the open updates being (or being perceived as)
>> less reliable than the closed. [That being said, we've already made
>> the decision to backport some major items; it's a delicate balance.]
> 
> I believe overseeing this is exactly the role of a maintainer and why we
> shouldn't cut them out of the picture for the majority of patches.

Yes, but it is difficult for a maintainer to push back against an
apparently reasonable patch at that stage in the process. The problem
is not that the individual patches are inappropriate, but that there
is a substantial volume of low-priority patches.

>> Where it makes sense, please minimize the size of the patches. If you
>> can adapt a backport patch to fit rather than also backporting a bunch
>> of its dependencies, please consider doing so. Bear in mind that
>> stability is the most important feature that these updates projects
>> have. Simple history in backports is important: it's more important to
>> reduce the volume of changes to 8u and 11u than it is to reduce the
>> differences between the backports and head.
>>
>> Feature backports should be treated with a degree of skepticism. 8u
>> and 11u are stable maintenance versions not development branches, so
>> features shouldn't be backported without a compelling reason and a
>> careful analysis of risk. Please discuss such backports on the list.
> 
> Again, I concur with Aleksey here that the default should be to backport
> dependants where possible. The viability of this is something for the
> patch review process and concomitant approvals, which again brings in
> the maintainer as well to give their opinion on whether such a backport
> is necessary.
> The problem with creating a more divergent change is that you then
> create a burden for future backporters; if patch x is backported with
> major alterations

... don't do that, then. I'm not talking about major rewrites of
patches. If a patch does require substantial backporting of
dependencies, we should look again at whether that patch is worth
doing.

> to avoid bringing in dependants, then patch y, which applies on top
> of x, has to then also be altered, whereas it may instead have been
> close to a clean backport if the divergence of x had been minimised.

That can happen. Use your judgment, but please try to keep the volume
of changes low.

> In short, it seems to me that the two sections here contradict one
> another; rule #0 seems to scream out for someone to oversee the
> overall set of patches being allowed into the update releases, while
> the second proposal risks excluding that same person from overseeing
> the majority of changes being made.

For this to work, everyone has to be part of the process, not just the
maintainer on one side and the committers trying to get stuff
in. Apart from anything else it's a terrible waste of effort once the
work has been done.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671