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/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
