Re: MAAS SRU
On Tue, Jan 29, 2013 at 07:40:03PM -0500, Andres Rodriguez wrote: > Request an exception to SRU MAAS to both Precise (and its required > dependencies) and Quantal. Thanks for raising this. You can find our decisions from yesterday's meeting here: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-February/001012.html -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MAAS SRU
On Tue, Jan 29, 2013 at 07:40:03PM -0500, Andres Rodriguez wrote: > [SUBJECT] > Request an exception to SRU MAAS to both Precise (and its required > dependencies) and Quantal. > > (Added for discussion to the agenda) Thanks. > [PROBLEM] > MAAS in Precise is obsolete and prevents users from having a full > experience of what MAAS is and brings to the deployment of bare metal with > Juju. > > When MAAS was first developed, as the successor of Orchestra, it heavily > depended on Cobbler to perform the operations it was designed for. The > first release of MAAS (released in Precise) depended on it (Cobbler) as the > 'maas-provision' package. However, due to several concerns about the > maintainship of Cobbler by upstream, as well as some security issues it was > decided that MAAS should drop the usage of Cobbler eventually. Indeed - I've understood this as the plan of record for some time. > When we first filed the MIR for MAAS in Precise, the MIR team review > pointed out various issues. After addressing all but three, we were > granted conditional MIR acceptance. The issues remaining were: > > - Remove Cobbler copy (maas-provision) [1] > - Remove raphael from MAAS source (and use package) [2] > - Remove yui3 from MAAS source (and use package) [2] > > These issues were resolved, and released in Quantal. Quantal MAAS no > longer depends on Cobbler (maas-provision), and it now utilizes the JS > libraries from packages in the archive, rather than shipping them along > with MAAS source. Because the new MAAS release dropped the usage of Cobbler > and introduced new features to replace the latter, it was decided not to > SRU MAAS from Quantal to Precise until MAAS matured, and several of the > possible (and actual) issues were resolved. Throughout the Quantal cycle, > the MAAS team and the Ubuntu Server Team worked together to resolve various > issues and make sure that the user experience is great. I agree with Steve's position on this. > In order for us to ensure that MAAS provides a great user experience, and a > critical bug free software, it is important that we SRU MAAS [3] to both > Quantal and Precise. The SRU involves: With Steve's amendments, I'm happy with this. I'd still welcome comments from others on the board. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MAAS SRU
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 Developerhttp://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
Re: MAAS SRU
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: > 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
MAAS SRU
Dear Technical Board, [SUBJECT] Request an exception to SRU MAAS to both Precise (and its required dependencies) and Quantal. (Added for discussion to the agenda) [PROBLEM] MAAS in Precise is obsolete and prevents users from having a full experience of what MAAS is and brings to the deployment of bare metal with Juju. When MAAS was first developed, as the successor of Orchestra, it heavily depended on Cobbler to perform the operations it was designed for. The first release of MAAS (released in Precise) depended on it (Cobbler) as the 'maas-provision' package. However, due to several concerns about the maintainship of Cobbler by upstream, as well as some security issues it was decided that MAAS should drop the usage of Cobbler eventually. At the time, given that Cobbler implemented far more features than required by MAAS, Cobbler created various issues when interacting with MAAS itself, and changes to Cobbler were required in order to ensure a successful user experience. Because we didn't want to affect the user experience of Cobbler as a standalone service, we decided to make a simplified copy of it and created the 'maas-provision' package. This also ensured us that we could drop 'maas-provision' once MAAS removed it as a dependency. When we first filed the MIR for MAAS in Precise, the MIR team review pointed out various issues. After addressing all but three, we were granted conditional MIR acceptance. The issues remaining were: - Remove Cobbler copy (maas-provision) [1] - Remove raphael from MAAS source (and use package) [2] - Remove yui3 from MAAS source (and use package) [2] These issues were resolved, and released in Quantal. Quantal MAAS no longer depends on Cobbler (maas-provision), and it now utilizes the JS libraries from packages in the archive, rather than shipping them along with MAAS source. Because the new MAAS release dropped the usage of Cobbler and introduced new features to replace the latter, it was decided not to SRU MAAS from Quantal to Precise until MAAS matured, and several of the possible (and actual) issues were resolved. Throughout the Quantal cycle, the MAAS team and the Ubuntu Server Team worked together to resolve various issues and make sure that the user experience is great. Given to the time constraints, some issues were unable to be fixed during the Quantal cycle; These are now fixed and included in Raring. Raring has a release version of MAAS which contains several fixes to MAAS released in Quantal. In order to allow the MAAS team continue the development of MAAS without affecting the resolution of issues, two upstream branches were created. - lp:maas - Upstream branch that contains the latest features. This is *NOT* released in Raring. - lp:maas/1.2 - Upstream branch containing resolved issues present in Quantal MAAS. This branch is mainly a bug fix branch of what was released in Quantal, and is currently released in Raring. [SOLUTION] In order for us to ensure that MAAS provides a great user experience, and a critical bug free software, it is important that we SRU MAAS [3] to both Quantal and Precise. The SRU involves: Quantal === For Quantal, the only required package to SRU is the 'maas' source package. 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: Django [4], [5], [6] - - In Order for MAAS to work correctly in Precise, we need to SRU 3 fixes to Django. These fixes have been fixed in Quantal and in upstream Django. 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. 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. [TESTING] Testing has been performed by the MAAS team. The MAAS Team commits to the maintainship of all the packages in question. The testing done includes both automated testing in the MAAS Lab, as well as manual testing by the MAAS team. [1]: https://bugs.launchpad.net/ubuntu/+source/maas-provision/+bug/975473 [2]: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/961344 [3]: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1109283 [4]: https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1081391 [5]: https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1081388 [6]: https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1081392 [7]: https://bugs.launchpad.net/ubuntu/+source/yui3/+bug/1084141 [8]: https://bugs.launchpad.net/ubuntu/+source/raphael/+bug/1084146 [9]: https://bugs.launchpad.net/ubuntu/+source/python-tx-tftp/+bug/11
