...

[Andrew Haley]

On 29/06/2020 17:38, Gil Tene wrote:
>> Or is it that all changes to JDK11u are in-principle bad, regardless
>> of their actual risk, which we should not consider?
>
> All feature additions in updates for an already released version (as
> opposed to bug fixes and security updates, which those updates
> are the vehicle for) are in-principle bad IMO. Sometimes we have to
> do the bad thing because it is less bad than the alternative (the LTS
> will break for many people if we don't do it). But it is still bad.

OK, so that is your position, and the in-principle argument is AFAICS
independent of the practical risk.

>> That possibility seems a little odd. Given that most of your post
>> is couched in terms of risk, to say that we shouldn't strive to
>> evaluate that risk would be downright irrational.
>
> The weighing of risk for adding a feature in a new OpenJDK version
> should be very different from the weighing of the same in an update
> to an existing version.

No question.

> When we add features to new versions (which we now get to do every
> six months), we don't risk regressing production behavior of people
> that depend on security updates to keep operating. We then consider
> the risk in terms of "will this impact adoption rate or make us look
> bad", and the benefits can be weighed against that risk. That's
> where the benefits of new features often get to win, and we can
> choose ways to minimize risk to help them win.

I agree. The benefits can be weighed against that risk.

> In contrast, when we consider adding features in an updates for an
> existing version (which will be forced on all production users that
> need to keep up with security, for example), the benefit of a new
> (did not previously exist in that Java version) feature should
> simply not be part of the equation unless it meets a base
> "necessity" requirement.  Without meeting that requirement, it
> should score a 0 on weight IMO.

That fits with my understanding of your position: no matter how
helpful a feature is, or how low the risk of adding it is, it should
not happen. So, your conclusion is *entirely independent* of the
actual ratio of risk to reward. No evaluation of either is necessary
because the conclusion will always be the same: no.

I hope that you will agree that your position on this matter is an
extreme one; in fact is the most extreme position it is possible for
anyone to take. You also know that this is not the position taken by
the whole community.

> Necessity has to do with fixing broken things, or preventing things
> from breaking. Not working on some new piece of hardware or a new
> version of OSs counts as "breaking" IMO, and security, correctness,
> and stability bugs do to. Even some seriously degenerate performance
> issues may be (although performance 2+ years into a release should
> not be something we should be working on improving within that
> release).

Please allow me to suggest a little thought experiment.

Let's say that we could import Feature X (which is Shenandoah, but I'd
like to do make this discussion more general) without any risk. Sure,
risk is never zero, but let's say:

1. All changes to the source code are surrounded by compile-time
   #if USE_SHENANDOAH_GC.

2. USE_SHENANDOAH_GC is never set unless it is explicitly requested by
   a configure argument.

3. All changes to the source code within the USE_SHENANDOAH_GC markers
   are also guarded by runtime tests of the form
   if (UseShenandoahGC) { ...

I maintain that no-one will ever be forced to use X. Firstly, no
downstream builder of our release JDK 11u will even build X unless
they explicitly choose to. Also, unless UseShenandoahGC is enabled on
the Java command line, no downstream user will be forced to use it
either.

What, in your opinion, are the practical risks to production users of
the above? I'm assuming that we can confirm that the above plan works
and does not touch anything it shouldn't by a combination of tooling
and several sets of eyeballs. That's not perfect, but nothing is.

-- 
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