Kernels built - copy to -proposed?

[Kate Stewart]

On Mon, 2010-12-06 at 10:54 -0600, Steve Conklin wrote:
> On Mon, 2010-12-06 at 08:19 -0800, Brad Figg wrote:
> > On 12/05/2010 11:28 AM, Kees Cook wrote:
> > > Hi,
> > >
> > > On Sun, Dec 05, 2010 at 12:17:56PM +0100, Martin Pitt wrote:
> > >> This is an issue for non-kernel SRUs, as they might be built against
> > >> libraries in -proposed with new symbols which aren't yet available in
> > >> -updates. As the kernel doesn't have runtime dependencies, this case
> > >> can't happen. The only corner case that I can see for this is if we
> > >> have a new toolchain bit in -proposed (like gcc or libtool) which
> > >
> > > I disagree here -- the ABI-tracking packages may include things outside the
> > > kernel too. I'm significantly more comfortable with doing the builds where
> > > they cannot possibly hit an -updates vs -security skew problem.
> > >
> > > Additionally, this gives the kernel team and QA significantly higher
> > > autonomy and an ability to not block on archive admins when starting the
> > > testing cycle.
> > >
> > >> isn't verified yet, so that the new kernel gets built with that. This
> > >> happens very seldomly, though, and I don't think it's an important
> > >> enough case to warrant making the normal kernel review process a lot
> > >> harder?
> > >
> > > I maybe do not understand what these tools are, but I thought the kernel
> > > was reviewed from -proposed before being promoted to -updates? If that's
> > > the case, than this change doesn't affect that since when the kernel is
> > > ready it would be copied into -proposed already.
> > >
> > > -Kees
> > >
> > 
> > Adding Kate to the distribution list.
> > 
> > Brad
> 
> I'd like for all of us to understand the concerns that each other has,
> and make sure that we're following the right processes. Also, we have
> certification and regression testing resources to be scheduled for
> these kernels, and the sooner we can let them know what our schedule is,
> the more easily they can manage their tasks.
> 
> Can we schedule a meeting as soon as possible on mumble and/or IRC, or
> even a conference call to discuss this? I think that it would help us to
> use a higher bandwidth channel than email to get this resolved.

+1

Kate