Re: Sarge TODO items
On Thu, Jun 03, 2004 at 12:19:56PM +0200, Christoph Hellwig wrote:
> On Thu, Jun 03, 2004 at 12:21:24PM +0200, Sven Luther wrote:
> > > detail. The common .config bit is of course also important! I'd love
> > > to move the fragments infrastructure of the 2.6 kernel-patch-powerpc
> > > to the generic kernel.
> >
> > Yep, Jens did a great job on this.
> >
> > As for the revision system, i would vote for subversion over the more
> > complicated arch. Many projects are using it already, Branden's X
> > packages, debian-installer, the ocaml team, ...
>
> subversions is fine with me. I'm not exactly happy with arch anyway,
> it's a little too clumsy for my test.
Fine with me. So let's create an alitoh project for the kernel, and a
subversion repo. Anyone is already looking into this ?
> So how do we move forward? Martin said he doesn't want major changes
> for sarge anymore which kind makes sense.
Makes sense. Best to keep major changes to post sarge.
> One thing is we should certainly check all current kernel packaging into
> SVN (minus kernel-patch-* that isn't used to build image, I think that
> part is clearly out of reach for the kernel team).
Yep. We have been refraining from creating a powerpc kernel subversion
repo waiting for this.
> For 2.2/2.4 let's follow his suggestion to not do any major changes,
> let's just try to move everyone to a single kernel-source for the
> patches to reduce overhead for the security team.
That means, a single kernel-source 2.4 and 2.2 version.
> Given the feedback I've heard so far it seems like 2.6 for sarge will
> only be for x86/alpha/ppc/ia64 and maybe s390. Given all of these don't
> require major patches and 2.6 isn't the main kernel for sarge I'd love
> to see a common packaging for those.
OWell, i still think that keeping the flexibility of allowing a per arch
patch set would be a good idea, even if this patchset is empty or almost
so. Let's start small though, create the subversion repo, and have the
kernel-source package moved in there. And then the porter will move
their own package to the subversion repo, and we can take a second phase
of moving patches from the per arch patches to the common kernel source
package once that is done. Small steps make for better going forward.
> So first thing would be to get a slight change in the kernel-source
> to actually allow us to apply multiple patches without bumping the
> version number, and I'm kinda stuck with that, so if someone familar
> with packaging could help out on that I'd be more than gratefull. And
> if you & Jens could integrate the powerpc packages into that like alpha
> I'd be a happy man already :)
Maybe, but later on. First let's have the infrastructure setup and such.
I still believe that having a kernel-source and many kernel-patch
packages building out of it (even with empty patches) would be more
robust in the long run. No need to rebuild every kernel-images if you
just changed one obscure config option in one of the powerpc subarches.
Also, another variable in this equation, is the handling of the NEW
queue. The powerpc 2.6.6-5 package is currently artificially hold back
in the NEW queue, and i have faced this kind of problems previously,
well mostly due to the intrusion, but still the package was uploaded at
least 3 weeks previous to the intrusion, so ...
I believe that we have to think about a solution to this if we want o
have quality kernel packages, and fast reaction to problems. A dedicated
kernel ftp-master maybe ?
Friendly,
Sven Luther
we want to achieve
Reply to: