linux-ports-meta -- Karmic/Lucid Ports Meta handling
Andy Whitcroft wrote:
> We have pulled the ports kernels back into the main repository and
> indeed the main branch for karmic and later. This has helped us
> mightily to keep those kernels up to date with respect to security
> updates and general fixing. However although we are updating the kernel
> itself we are not taking any role in handling the linux-ports-meta and
> therefore which kernel is selected for the ports architecture.
> Obviously as failures in the ports kernels are not blockers for the
> other architectures we do need the meta updates for distro kernekl and
> for ports kernels to be separate uploads to allow ports to lag should
> they require.
> Right now we have an issue particularly for -security updates where we
> produce the entire stack and that has to be passed to the security team
> for upload. linux-ports-meta does not get included in this and
> therefore was missed for the recent karmic security update.
> I am wondering if linux-ports-meta should be pulled back into kernel-team
> 'responsibility' so we are responsible for keeping it in lockstep
> for -security and -updates updates for karmic now and lucid and on as
> they release. That leave the issue of where to find and update the
> meta package, it may make sense to pull linux-ports-meta back into the
> linux-meta repository as a ports branch.
> Anyhow, my aim here is to start some discussion on where we should go
> with this. My personal feeling is that pulling the ports source back
> to the main repository has been very beneficial adding little work to
> our team and significantly reducing the load on the ports owners while
> keeping us in near lock step for the whole of karmic/lucid. I suspect
> that pulling meta back would have similar benefits, though we would want
> some interlock on testing with the ports maintainers.
I agree with your points. I was initially hesitant to take on the ports
workload, but it has proved to be less effort then I expected. I suspect
ports meta will benefit from the same treatment while not really causing
us too much pain.
Tim Gardner firstname.lastname@example.org
kernel-team mailing list