[FREEZE] 11.0.3 NOW FROZEN

[Andrew Haley]

On 4/2/19 9:00 AM, Aleksey Shipilev wrote:

> I suggest, once again, that we mechanically lock the repository when
> we don't accept the pushes. Let only the maintainers to push. Then
> Andrew can push the CPU update himself before unfreezing the repo.
> 
>> [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe
>> [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a68aa56930c0
>> [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/22cfec306339

OK, OK, you're right. We can make those changes after the CPU.
Never let it be said that I'm too stubborn to admit when I'm beaten.
:-)

Thinking some more, though, this illuminates a real problem in our
processes.

A rule of user interface design is that actions should be easily
reversible:

  Make actions reversible (be forgiving)

  This rule means that the user should always be able to quickly
  backtrack whatever they are doing. This allows users to explore the
  product without the constant fear of failure -- when a user knows
  that errors can be easily undone, this encourages exploration of
  unfamiliar options. On the contrary, if a user has to be extremely
  careful with every action they take, it leads to a slower
  exploration and nerve-racking experience that no one wants.

  https://theblog.adobe.com/4-golden-rules-ui-design/

It's clear to me that our source control system and its interaction
with the bug database fails this rule, and spectacularly so. A
contributor should be able to say "oops!" after a mistaken checkin and
easily undo it. Today, though, backing out a change requires
interaction between multiple people and systems and a public apology.

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