MAAS SRU

[Steve Langasek]

Dear Tech Board, Andres,

On Tue, Jan 29, 2013 at 07:40:03PM -0500, Andres Rodriguez wrote:
> Precise
> =======

> In order for MAAS to be able to SRU MAAS to Precise, we are also required
> to SRU some other packages and fixes. These include:

<snip>

>   yui3 [7], raphael [8]
>   ---------------------
>    - Given that MAAS no longer includes the YUI3 and raphael JS libraries
> in its source, we need to SRU both of these packages to Precise. This
> involves SRU'ing two new packages for precise, as their initial release is
> Quantal.

The requirements for the MIR are in effect precisely opposite to the
requirements for SRUs.  It's absolutely correct that for an MIR, we don't
want the package to ship a bundled copy of software that's available in
other packages in the archive, we want it to use a package dependency
instead.  For an SRU, however, the guiding principle is to make changes to
the package /minimal/ in order to avoid collateral damage.

The raphael package currently in precise is there for its own reasons,
unrelated to MAAS.  Updating this package to a later upstream version
without following the SRU guidelines, solely to enable MAAS to split it out
of its own source for an SRU, is not a minimally-invasive change, and it's
not in the best interest of either the existing users of raphael or of the
MAAS team to go this route; it will result in an unverifiable SRU that will
take an indefinite amount of time to get through the system, at the end of
which it still may or may not cause regressions for other users.

Whereas if you can instead re-add the desired version of raphael to the maas
package that you're SRUing, we don't need to worry about external
dependencies on raphael and can focus on verification of maas itself.

It's for this reason that I rejected the raphael SRU from the queue, as
noted in the bug:

  https://bugs.launchpad.net/ubuntu/precise/+source/raphael/+bug/1084146

Please just bundle raphael back into the maas SRU; it's better for everyone
concerned.

yui3 is in a different situation; as the package currently does not exist at
all in precise, there's no risk of regression from introducing it now.
However, my suggestion to the MAAS team is that you continue to bundle yui3
in the maas source in precise, so that you don't face the same questions for
any *future* updates to maas: if you provide a yui3 package in
precise-updates, users *will* rely on it, and it will need to follow the SRU
policy, which I think will make SRU verification unnecessarily burdensome
for you (and SRU review unnecessarily time consuming for the SRU team).  If
you keep it as an internal implementation detail of the maas package the way
it is right now in precise, we don't have to worry about interface stability
to outside consumers.

>   python-tx-tftp [9]
>   ------------------
>    - This is a new dependency of MAAS (since Quantal), which provides MAAS
> with the TFTP server it implements. This package is maintained by the MAAS
> team as well as provides upstream fixes to it. This is an essential
> dependency of MAAS.

I think the same arguments apply here as for yui3, but to a much lesser
degree because the code is less widely used and has a much smaller interface
surface area.  So I have no objection to introducing this as a new package
in precise to satisfy the maas dependency, as I consider the separate source
package a trivial implementation detail.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20130130/14083503/attachment.pgp>