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/
slangasek@ubuntu.com vorlon@debian.org
