On Tue, Mar 22, 2016 at 12:02:43PM +0100, Martin Pitt wrote: > Steve Langasek [2016-03-18 21:48 -0700]: > > FWIW I don't agree; we already have component-mismatches which we have a > > committment to drive to zero for release, and the teams that have introduced > > the new dependencies are responsible for driving the MIRs for those > > packages.
> While we have the formal commitment, in reality we have just moved > some packages to main without an MIR on the second-to-last day before > release, and have ignored large chunks of c-m for several releases. And we have also been releasing phone images out of universe for the past two years, bypassing the MIR review process both for the initial image and for subsequently added packages even though the Security Team is on the hook to support them, because the MIR process has included so much makework for packages not on the images that it was considered expedient for the team to ignore it entirely. There is no rearrangement of the contents of the components that is going to completely eliminate the tension around MIRs. But by eliminating the makework around packages that we don't actually have an interest in supporting, we can hold teams accountable for what remains; and the tension around MIRs at that point is a healthy one about what/how much we support. > I doubt it would go well if two days before the release built images > would suddenly lose 20 new packages (and presumably break them > completely). I see no practical way that the release team would do > that without getting yelled at from all sorts of directions. I'm coming at this from the perspective that if a package has been mandated to be seeded on the images, the real question is *how* to support this, not *whether* we will support it. The MIR process provides an important check to make sure we aren't inadvertently pulling in multiple implementations of something that will be a security support burden later, or depending on things that are badly designed. If our MIR process is providing a sanity check against dependency creep, a queue for the Security Team to ensure packages are sanely supportable, and a clear accounting of what team is responsible for maintenance of the package; and if it accomplishes this without getting in the way of the developers preparing the next release; that, IMHO, is when the MIR process is fulfilling its intended purpose. When I have to have conversations each cycle with folks explaining that an important new product feature isn't available yet by default in an image for testing because its dependencies are still in the MIR queue, the MIR process is falling well short of this ideal. Allowing prerelease images to build from universe would be one way to address this problem. Another would be to abandon the use of component-mismatches as the authoritative list of in-progress promotions, instead opening the MIR bugs, "pre-promoting" packages, and using the open MIR bug list as the driver. I'm satisfied that the build-depends changes alone will make a noticeable difference in our velocity around MIRs, so I'm not pushing for a perfect solution to the above problem. I do think it's still a problem, however, and one we may want to revisit later. > > However, thanks to Dimitri's patch to proposed-migration, which has been > > landed[1], it seems we don't have to come to an agreement on this point to > > unblock this change. > This helps a bit indeed, but does not help with universe packages that get > seeded directly? E. g. the current bunch of packages on the > system-image seed on c-m. It certainly does not remove the need for process - and healthy discussion - around product decisions that expand the set of software that we are supporting, no. -- 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
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
