Re: 2.6.23 upload to p-u
On Fri, Jan 11, 2008 at 05:10:22PM +0100, maximilian attems wrote:
> On Fri, Jan 11, 2008 at 04:01:57PM +0100, Martin Michlmayr wrote:
> > * dann frazier <email@example.com> [2008-01-10 23:08]:
> > > I plan to upload the first linux-2.6.23 for etchnahalf this coming
> > > Sunday. The changes I have in mind before then are:
> > I'm a bit surprised since I haven't seen any discussion about this on
> > debian-kernel recently. I'd like to enable some options in the
> > etchnahalf kernel that are currently not enabled in sid's 2.6.23
> > (because they'd change the ABI). Can I make changes directly to
> > dists/etch/linux-2.6.23 or will that make your merges too complicated?
> triple wooow too.
> where were the discussion about the picked version?
> i nack 2.6.23 until i see such a discussions,
> with the args why 2.6.23 is chosen?
I'd thought 2.6.23 was the agreed upon release (there were requests
along the line of "might as well wait for .24 now", but there's still
no upstream release). Clearly that's not the case..
maks pulled me aside on IRC, and pointed out a number of issues with
2.6.23; and a strong preference for either 2.6.22 or 2.6.24
instead. I've really no strong opinion about a version myself - either
would be fine with me. Of course, 2.6.24 is still not released, and
therefore hasn't had time in the sid testbed, so its too early imo to
pick that one.
So, here's the proposal we came up with (maks: correct me if this
doesn't line up w/ your understanding):
* Go with 2.6.22 for now - its more stable than 2.6.23 and is a known
quantity. I could get a branch going and start on any security
fixes, and upload sometime soon, perhaps Wednesday?
* Encourage users to test 2.6.24 rc releases - maks wants to make rcs
available in experimental, and try for a quick upload to sid once
* 4.0r3 is intended to happen in February, and mainly to fix issues
with 4.0r2 - 4.0r4 would be the next candidate for etchnahalf.
* Revisit the 2.6.22 decision once 2.6.24 has been in sid for 2
weeks. If 4.0r4 is still far enough out (e.g., if 4.0r3 hasn't
happened by this point), and no major issues have been uncovered so
far, it seems reasonable to switch.