Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Sat, Dec 02, 2006 at 02:41:08AM -0800, Steve Langasek wrote:
> On Sat, Dec 02, 2006 at 10:51:57AM +0100, Sven Luther wrote:
> > The -k7 issue, i don't know, can it be a flavour that was dropped or
> > something ?
>
> linux-latest-2.6 is not a candidate because not yet uploaded on sparc.
> That's the easy part; linux-modules-extra-2.6 is the harder part, currently
> failing to build on both arm and s390 (c.f. bug #400220).
Can we not just scratch l-m-e-2.6 until those issues are fixed, and migrate
linux-2.6 andl-l-2.6 into testing asap ? We need to get more testing done for
it.
> > > > - What are our plans for 2.6.19 ? Will we have it enter unstable, and
> > > > maintain the etch kernel through testing-proposed-updates ? I heard this
> > > > mentioned some time back. Will we fork a linux-2.6.19 package in unstable
> > > > ? Will we keep 2.6.19 in experimental for now ?
>
> > > I hope you can keep 2.6.19 in experimental for now - it doesn't take so
> > > long to release Etch anymore.
>
> > Bah, we where told this for sarge, and it took over a year back then. I don't
> > see us releaseing etch anytime soon, since we don't have had a single release
> > candidate of d-i with the 2.6.18 kernels in it yet, so moving 2.6.19 to
> > unstable (maybe with a linux-2.6.19 source package) should be nice enough. We
> > did this already for 2.6.16, so, we know how to do this.
>
> Frankly, 2.6.16 was a total cock-up. Aside from all the extra work it made
> for the release team, I even found patches I had to reapply for alpha
> because they were dropped on the floor when 2.6.16 was merged to trunk. I
> am very much opposed to having two kernel versions in unstable at the same
> time.
Well, the idea is to continue working on 2.6.19 in a separate package, but
keeping 2.6.18 linux-2.6 as the main package, with linux-2.6.19 being a
separate package which will be worked on as separatedly for those peopel who
want.
But you are right, if we want to do more than one kernle, we need an automated
better way to do synchronizations.
Friendly,
Sven Luther
Reply to: