On Thu, Jan 20, 2011 at 07:30:35PM +0100, Loïc Minier wrote: > As a followup to IRC conversations around backports, releases and QA > today, I'd like to hear what others think of our Linaro PPAs. I'll > start with some history and proposals:
> We created a fairly ad hoc PPA layout for the 10.11 cycle, with > ppa:linaro-maintainers/tools > ppa:linaro-maintainers/override > ppa:linaro-maintainers/kernel > and nowadays we also have this PPA for toolchain backports: > ppa:linaro-maintainers/toolchain > and misc other PPAs which I don't really know much about: > ppa:linaro-maintainers/user-platforms > ppa:linaro-toolchain-dev/ppa > ppa:linaro-infrastructure/launch-control > ppa:linaro-infrastructure/launch-control-snapshots > (and probably many more) > There are multiple problems with our current approach: > * ~linaro-maintainers membership is poorly defined > * it's not clear which software should go in which PPA > * it's not clear when we can update which PPAs, e.g. can we update them > after 6-monthly releases? how do we QA/validate updates? Alexander and I discussed the linaro-maintainers team status last week at the sprint; as I mentioned to Loïc on IRC, the basic plan going forward is this: - blueprint handling will be split off of linaro-maintainers to a separate linaro-drivers team, leaving -maintainers for ppas and bzr branches - many of the existing members of linaro-maintainers will have their membership deactivated - membership in -maintainers will be managed by the current admins accordingly; only people who need to upload to these ppas or commit directly to the branches will be in this team, and the admins will determine based on package sponsorship history when a prospective uploader is ready for direct commit/upload access - the overlay ppa is the only one that should be enabled for Linaro release images, and anyone who needs additional packages not available there included in the images should work with the DevPlatform team to get them into either the Ubuntu archive or this ppa I do not want us to be managing per-image PPAs for any 6-month release images, nor do I want us to be pulling multiple PPAs into the sources for our images. It is the responsibility of the DevPlatform team to assemble the output of the working groups into a cohesive, integrated whole that showcases the Linaro development, and this necessarily implies a certain amount of selectivity in terms of which versions of component releases we take in from the working groups and when. The "component release" plan put forward by Kiko involves a relatively lightweight QA process on the monthly releases and I don't want to impose further overhead on these monthly releases per se, which means instead that integrating component releases into the Linaro eval images / 6 month releases (by way of either the Ubuntu archive or the overlay ppa) involves a manual pull. This is something I intend to discuss with the WG TLs over the next week to ensure we're aligned with them in terms of what outputs we should be integrating when. As for the 'tools' ppa, I had envisioned this as the single ppa that developers should enable on their desktop systems to get tools they need to work with, and develop for, current Linaro development images, particularly when those desktops are running older versions of Ubuntu. So backports of the current version of qemu, for instance, that are able to boot the latest images, and linaro-image-tools that work with the new 11.05 hwpack format and can pass the right boot args for newer kernels, are the kind of thing I would like to see here. I don't intend us to guarantee that the packages won't cause regressions vs. those versions shipped in that Ubuntu release - indeed, we know for certain that the new linaro-image-tools won't work with images released with 10.11 - but they will be the best tools we can give you for working with Linaro images while minimizing regressions where possible. The 'kernel' ppa is something of a mixed bag. There are a variety of test kernels, bsp kernels and pre-release kernels available there, including those we used for our bsp hwpacks in 10.11. It lacks a clear policy, and I'm pretty sure we don't want Landing Teams to be bottlenecked on this single PPA for their ability to build kernel packages (and hwpacks). But I wouldn't do away with this altogether; it's clear to me that John has been getting good use out of it. > In general, it's good to avoid PPA proliferation, both for sanity and > for the confort of our end users, but I think a consistent set of PPAs > is more important than trying to optimize the number of PPAs to the > smallest subset possible. > Some ideas on addressing this: > * have software ownership split by team; ~toolchain owns gcc-linaro and > qemu-linaro, ~infrastructure owns > * have each team decide between either: > - a single PPA for all their outputs (e.g. ~infrastructure/ppa for > linaro-image-tools and gcc-log-analyzer) > - or multiple PPAs, one per software (e.g. ~toolchain/gcc-linaro PPA > for gcc-linaro, ~toolchain/qemu-linaro PPA for qemu-linaro) > * optionally, additional PPAs for dailies > * optionally, additional PPAs for RC releases I think it's a good idea to have per-WG PPAs where the working groups can upload packages of their monthly component releases, of dailies, and any other WG output they want packages of - however they happen to be split up. > Open questions: > - do we upload latest release of e.g. gcc-linaro to the natty toolchain > PPA if it already gets uploaded to natty proper? Provided that the PPA uploads use proper version numbers (i.e., don't shadow any version number that would be used in the Ubuntu or Debian archives), I think this is reasonable. We can't generally guarantee any particular time frame for inclusion in natty after the WG component is released, so I think it's simpler to have a policy of "always PPA upload". 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
signature.asc
Description: Digital signature
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
