Dear Tech Board, Steve, Steve, first let me thank you for your review and suggestions.
We were working with the assumption that the JS libraries should be separated from the maas source package. However, based on your arguments, we have no objections to continue to ship these JS libraries within the maas source. We agree that doing so makes our lives much easier, introducing minimal changes to the archive. Thank you! Best regards. 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/ > slanga...@ubuntu.com vor...@debian.org > -- Andres Rodriguez (RoAkSoAx) Ubuntu Server Developer Systems Engineer
-- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
