Transitioning Controller to being MRI

Robert Varga

Hello everyone,

controller committers have decided to transition the project to being
release integrated many moons ago. Unfortunately execution has been
postponed by various things happening -- and there are only a few points
during our lifecycle when such a transition is easily doable.

Since stable/magnesium and master for MSI projects are currently
synchronized with regards to MRI project versions and given the
interdependencies of Aluminium MRI window[0], NOW is the time to take

The process involves three steps:

1) transition all of controller's downstreams to use Magnesium version
of controller artifacts
2) remove controller from autorelease
3) remove controller's distcheck jobs
4) perform a normal MRI bump during the Aluminium MRI Integration Window

I have staged the patches for 1 through 3 here:"controller-mri"

Multipatch-test is running here:

Once that job succeeds, I will be asking for supercommitter rights to
get those patches merged, after which controller's master will become
disconnected from MSI projects participating in Aluminium SimRel.

This transition may break some things (around patch tests involving
controller). There is no known cook book at to what exactly needs to be
fixed and how, and the last time we did this was a long time ago, it was
mdsal, and the transition was executing in between branch and release of
... Fluorine was it? At any rate, such breakages do not really block
anything and we'll figure them out as we go.

If anybody has objections, holler now, or hold your peace (and watch the


[0] odlparent brings Guava-28, which in turn makes Controller's
sal-{dom,binding}-api untenable, hence those have to go before
odlparent-7 is integrated, which really means we need controller/master
to make changes which cannot pass distcheck, as there are still laggard
downstreams using those APIs.

Join to automatically receive all group messages.