linux-ports-meta -- Karmic/Lucid Ports Meta handling
Stefan Bader
stefan.bader at canonical.com
Thu Jan 21 13:48:00 UTC 2010
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.
>
> Thoughts?
>
> -apw
>
I agree this should not create much overhead and prevents skips like they are
currently happening. In theory (if people on ports kernel have proposed enabled)
this will also help to spot problems in ports updates which the update is in
proposed.
A similar issue has risen for the topic branches with respect of security
updates. But that probably needs to be discussed in a seperate thread.
-Stefan
More information about the kernel-team
mailing list