Started logging meeting in #debian-release<br />
[18:00:49] * dannf reloads the agenda wiki<br />
[18:01:20] &lt;dannf&gt; if that's it, lets get started<br />
[18:01:22] &lt;luk&gt; Pete_B: no, they were mentioned, it was not decided to have them included already...<br />
[18:01:31] &lt;dannf&gt; #topic is it still a good idea?<br />
<a name='0'></a>
[18:01:38] &lt;Pete_B&gt; luk: ok<br />
[18:02:02] &lt;luk&gt; sure it's still a good idea, why would you think otherwise? :-)<br />
[18:02:08] &lt;dannf&gt; i guess the best way to deal with this topic is to see if anyone has objectiosn?<br />
[18:02:15] &lt;waldi&gt; the necessary work<br />
[18:02:19] &lt;otavio&gt; Personally I think it's .. some new hardware has problems with 2.6.18 (specially new laptops) <br />
[18:02:59] &lt;dannf&gt; waldi: is that an objection?<br />
[18:03:18] &lt;luk&gt; which brings us to what do we want to achieve with EtchAndAHalf<br />
[18:03:30] &lt;waldi&gt; dannf: yes<br />
[18:04:13] &lt;luk&gt; waldi: can you please be a bit more verbose?<br />
[18:05:57] &lt;luk&gt; what work is necessary for EtchAndAHalf that is not needed otherwise which makes you object?<br />
[18:06:39] &lt;waldi&gt; luk: the kernel is the largest part of this. currently there are two persons working on the core kernel support, one does work on the .18 etch kernel<br />
[18:07:10] &lt;waldi&gt; i doubt that anyone of them can handle another complete set<br />
[18:08:10] &lt;otavio&gt; what worries me is the security team needing to take care of two completely different kernels<br />
[18:08:19] &lt;dannf&gt; if we don't have the manpower, it will fail - so perhaps we can postpone this to the discussions about who does what<br />
[18:08:23] &lt;luk&gt; AFAICS sarge's kernel will not be handled once EtchAndAHalf is there...<br />
[18:08:35] &lt;dannf&gt; otavio: we've already agreed to do so; the timing is set so that the sarge kernels are no loner security maintained at that point<br />
[18:08:47] &lt;otavio&gt; dannf: ah ok<br />
[18:08:49] &lt;azeem&gt; luk: both both etch and etchandhalf will be there when lenny arrives...<br />
[18:08:52] &lt;azeem&gt; but*<br />
[18:09:13] &lt;dannf&gt; that's understood<br />
[18:09:16] &lt;azeem&gt; or will support for etchandhalf be dropped then?<br />
[18:09:17] &lt;dannf&gt; (by the security team)<br />
[18:09:25] &lt;azeem&gt; would make sense, probably<br />
[18:09:27] &lt;azeem&gt; ok<br />
[18:09:30] &lt;dannf&gt; let's discuss security support later<br />
[18:09:55] &lt;otavio&gt; I see many pros and only one cons (man power)<br />
[18:10:13] &lt;dannf&gt; so i hear one objection of it'll take more work, and we may not have the manpower to do that - I vote we get through the rest of the discussion, then come back to who does what and see where the holes are<br />
[18:10:23] &lt;otavio&gt; as waldi said, it does require man power to be done<br />
[18:11:15] &lt;dannf&gt; if we find we don't have the manpower, we can either scrap it or change the goals<br />
[18:11:39] &lt;dannf&gt; #topic kernel - known issues w/ 2.6.23<br />
<a name='1'></a>
[18:12:02] &lt;dannf&gt; specifically, are there problems with 2.6.23 that make it unsuitable in an etch environment<br />
[18:12:24] &lt;waldi&gt; iwconfig AFAIK<br />
[18:12:32] &lt;tbm&gt; the problem I see  is that we still don't have 2.6.23 in unstable, so 2.6.23 hasn't had any testing in Debian yet<br />
[18:12:44] &lt;otavio&gt; yes. It would require binary NMUs ... <br />
[18:12:48] &lt;tbm&gt; also, Debian's 2.6.23 removed from driver that we do want to have in etch<br />
[18:12:58] &lt;otavio&gt; waldi: well but if we move to new iwconfig, we won't work with .18<br />
[18:13:09] &lt;waldi&gt; otavio: it should work<br />
[18:13:23] &lt;waldi&gt; AFAIK it is backward compatible<br />
[18:13:31] &lt;otavio&gt; waldi: really? I thought it wasn't<br />
[18:13:32] &lt;otavio&gt; waldi: ok<br />
[18:13:52] &lt;otavio&gt; tbm: which? <br />
[18:13:54] &lt;waldi&gt; sis already switched to libata<br />
[18:14:04] &lt;tbm&gt; otavio: e.g. tg3<br />
[18:14:13] &lt;luk&gt; 2.6.23 needs to be well tested before we would consider to include it IMHO<br />
[18:14:21] &lt;otavio&gt; tbm: this is next topic :-)<br />
[18:14:21] &lt;waldi&gt; tbm: tg3 is fixed<br />
[18:14:24] &lt;dannf&gt; tbm: i think 2.6.23 in unstable should happen first<br />
[18:14:43] &lt;otavio&gt; dannf: ack<br />
[18:14:49] &lt;luk&gt; ack<br />
[18:14:52] &lt;waldi&gt; yep<br />
[18:15:04] &lt;luk&gt; probably even testing<br />
[18:15:11] &lt;tbm&gt; so what's the holdup to get 2.6.23 into unstable?<br />
[18:15:16] &lt;waldi&gt; d-i<br />
[18:15:16] &lt;otavio&gt; #aggred 2.6.23 in unstable should happen first<br />
[18:15:18] &lt;otavio&gt; :-)<br />
[18:15:29] &lt;otavio&gt; dannf: you could record that :-)<br />
[18:15:33] &lt;dannf&gt; #agreed 2.6.23 in unstable should happen first<br />
<a name='2'></a>
[18:15:44] * Sledge has seen current hardware already that needs > 2.6.23 ... :-(<br />
[18:15:56] &lt;otavio&gt; tbm: we're holding it :-)<br />
[18:16:07] &lt;otavio&gt; tbm: udebs probably going to happen later today or tomorrow<br />
[18:16:21] &lt;dannf&gt; i wouldn't want to say 2.6.23 has to be in testing first; it may make more sense at the time for 2.6.24+ to be the next goal<br />
[18:17:21] &lt;otavio&gt; but if we go to 2.6.24, it lose importance since Lenny won't be too far<br />
[18:17:24] &lt;dannf&gt; as for iwconfig, i think having a working iwconfig is a must, can we agree on that?<br />
[18:17:34] &lt;otavio&gt; dannf: yes<br />
[18:17:37] &lt;dannf&gt; (for both 2.6.18 and 2.6.23)<br />
[18:17:47] &lt;otavio&gt; dannf: it would require to check if it's backward compatible<br />
[18:18:03] &lt;dannf&gt; #agreed iwconfig will need changes to work with both kernels, and that is a must for etch and 1/2<br />
<a name='3'></a>
[18:18:29] &lt;dannf&gt; i don't think we need to solve the details here, but we'll record that as a rqmt for now<br />
[18:18:48] &lt;dannf&gt; any more on known-issues-w/-2.6.23 in etch?<br />
[18:18:57] &lt;otavio&gt; Xen is one<br />
[18:18:58] &lt;waldi&gt; sis<br />
[18:19:05] &lt;waldi&gt; Xen is not available<br />
[18:19:09] &lt;otavio&gt; AFAIK XEN isn't supported as Dom0<br />
[18:19:33] &lt;waldi&gt; and the support does not work with xen 3.0.3<br />
[18:19:38] &lt;dannf&gt; i'd like to postpone xen for the discussion on features<br />
[18:19:46] &lt;otavio&gt; dannf: ok<br />
[18:19:53] &lt;otavio&gt; waldi: what's the problem with sis?<br />
[18:20:23] &lt;waldi&gt; otavio: libata<br />
[18:20:32] &lt;dannf&gt; (features is the next topic)<br />
[18:20:46] &lt;luk&gt; dannf: so change to the next topic :-)<br />
[18:20:52] &lt;dannf&gt; waldi: more details please<br />
[18:21:46] &lt;otavio&gt; dannf: please, change to next topic :-)<br />
[18:21:49] &lt;waldi&gt; dannf: sis pata support switched to libata<br />
[18:21:57] &lt;dannf&gt; waldi: ok, sounds like good next topic material :)<br />
[18:22:13] &lt;dannf&gt; #topic kernel -- feature differences w/ 2.6.18<br />
<a name='4'></a>
[18:23:11] &lt;dannf&gt; at debconf, the consensus was that we didn't necessarily need to have all the features of 2.6.18 - e.g., if we didn't have xen flavours, or support for all archs, that was ok<br />
[18:23:16] &lt;luk&gt; feature differences should not be a blocker IMHO as we can always point at the other kernel, though should be avoided if easily possible<br />
[18:23:47] &lt;luk&gt; s/archs/subarchs/<br />
[18:24:32] &lt;otavio&gt; dannf: you skiped the blob striping rules topic .. please move to it, after this one finishes<br />
[18:24:51] &lt;dannf&gt; does anyone object to that? this isn't to say that, e.g., xen *couldn't* be there, but its not a must<br />
[18:25:04] &lt;otavio&gt; dannf: ack on that<br />
[18:25:07] &lt;dannf&gt; otavio: that's the next one down on the wiki (may need a refresh)<br />
[18:25:14] &lt;otavio&gt; dannf: otherwise 3.1 moving<br />
[18:25:27] &lt;dannf&gt; waldi: reasonable to you?<br />
[18:25:32] &lt;otavio&gt; dannf: and I think it's not desired<br />
[18:25:39] &lt;otavio&gt; waldi: is vserver OK for .23?<br />
[18:25:41] &lt;waldi&gt; no objection<br />
[18:25:51] &lt;waldi&gt; otavio: not yet, will need some more days<br />
[18:26:10] &lt;otavio&gt; waldi: but it ought to be OK for it?<br />
[18:26:11] &lt;dannf&gt; #agreed feature and subflavour support does not have to match 2.6.18<br />
<a name='5'></a>
[18:27:06] &lt;Pete_B&gt; I can see that causing confusion amongst users, there being differing versions of releases, one with only a subset of features of the previous<br />
[18:27:07] &lt;luk&gt; next topic please<br />
[18:27:13] &lt;dannf&gt; as for archs - if say, the sparc flavor is broken, would we consider that rc, or ship w/o sparc/<br />
[18:27:42] &lt;pusling&gt; sparc as the debian arch ?<br />
[18:27:59] &lt;luk&gt; it depends on the issue IMHO, we would certainly prefer to have all release archs included<br />
[18:28:00] &lt;dannf&gt; no, the 2.6.23 kernel images<br />
[18:28:06] &lt;otavio&gt; dannf: I think all arches at least need to be supported<br />
[18:28:10] &lt;Md&gt; (I would love to see a new kernel in etch.5, because udev in lenny will soon require something like .21 or .22)<br />
[18:28:16] &lt;otavio&gt; dannf: features are OK but arches would be too confusing<br />
[18:28:47] &lt;waldi&gt; sparc64 is supported and should work, sparc32 is not<br />
[18:29:13] &lt;luk&gt; well, sparc32 not being supported would be OK IMHO<br />
[18:30:04] &lt;dannf&gt; otavio: how about  we support all archs that were supported in etch and plan to be supported in lenny?<br />
[18:30:14] &lt;dannf&gt; as our stated goal<br />
[18:30:47] &lt;otavio&gt; dannf: sparc32 was supported and doesn't look to be possible to be on .23 ...<br />
[18:30:54] &lt;otavio&gt; dannf: it looks confusing from user pov<br />
[18:31:05] &lt;tbm&gt; are new subarches ok?<br />
[18:31:38] &lt;pusling&gt; otavio: dropping subarchs has just been agreed upon doesn't have to match<br />
[18:31:44] &lt;dannf&gt; tbm: i would vote yes<br />
[18:31:52] * luk would vote yes too<br />
[18:32:18] &lt;Sledge&gt; tbm: I'd say so, depending on the work involved<br />
[18:32:19] &lt;waldi&gt; including d-i support?<br />
[18:32:31] &lt;dannf&gt; #agreed dropping/adding subarchs for the kernel is ok<br />
<a name='6'></a>
[18:32:48] &lt;luk&gt; otavio: sparc32 will not be supported for lenny anymore, so users of sparc32 will get confused at some point anyway, better soon than later IMHO<br />
[18:33:03] &lt;otavio&gt; I'm unsure how much work on d-i to support this mixed set of versions will be required<br />
[18:33:27] &lt;otavio&gt; luk: eheh well but it's for etch<br />
[18:33:35] * dannf suggests postponing d-i topics till we get to d-i in the agenda<br />
[18:33:37] &lt;otavio&gt; luk: and this is going to be a etch kernel<br />
[18:33:58] &lt;otavio&gt; luk: they're two different things to me: etch x lenny<br />
[18:33:58] &lt;luk&gt; no, eth.5 should really not be called etch IMHO<br />
[18:34:16] &lt;dannf&gt; we ready for next topic?<br />
[18:34:39] &lt;Pete_B&gt; sorry to be a little off-topic, it seems to be a shared understanding that I'm not getting, why is Etchandahalf not going to be Debian 4.1 and so replace Debian 4.0, sidestepping the need to support both as Debian Stable and be so Etch-compatible?<br />
[18:34:43] &lt;luk&gt; yes, as ready as can be<br />
[18:35:09] &lt;dannf&gt; oh - wait, we didn't cover modules/kernel-patches  - i would think that we'd use the same principles we do today - external modules that are ready are ok, those that aren't can be dropped (even if they were in etch)<br />
[18:35:50] * Sledge nods dannf - sounds sane<br />
[18:35:51] &lt;dannf&gt; Pete_B: etch 1/2 in theory only adds packages to etch - doesn't force people to upgrade<br />
[18:35:52] &lt;luk&gt; Pete_B: security and other support is promissed to the users, so we cannot just drop etch<br />
[18:36:10] &lt;luk&gt; plus what dannf said<br />
[18:36:22] &lt;otavio&gt; dannf: iwconfig will change things on etch :-)<br />
[18:36:30] &lt;luk&gt; dannf: yes, sounds sane<br />
[18:36:32] &lt;otavio&gt; dannf: and other things too, probably<br />
[18:36:52] &lt;otavio&gt; dannf: I think modules need to be considered base by case<br />
[18:36:56] &lt;dannf&gt; #agreed external modules/patches available for 2.6.18 don't need to be there for .23<br />
<a name='7'></a>
[18:37:00] &lt;dannf&gt; otavio: i said "in theory" :)<br />
[18:37:03] &lt;otavio&gt; dannf: it depends if it's easy to fix or not<br />
[18:37:33] &lt;dannf&gt; otavio: unless its easy but noone does the work - in that case it shouldn't be a reqmt imo<br />
[18:38:04] &lt;otavio&gt; dannf: yes, ack <br />
[18:38:08] &lt;luk&gt; dannf: than it doesn't seem to be as easy as one thinks :-)<br />
[18:38:19] &lt;otavio&gt; luk: hehe<br />
[18:38:40] &lt;dannf&gt; #topic kernel -- firmware stripping rules<br />
<a name='8'></a>
[18:39:17] &lt;dannf&gt; should we comply with etch or post-etch rules for fw-stripping?<br />
[18:39:40] &lt;otavio&gt; dannf: if we're using the lenny set of archs and like, it looks logical to us follow it<br />
[18:39:55] * dannf thinks so too<br />
[18:40:29] &lt;dannf&gt; and since we already agreed on feature-parity not being a requirement, it seems reasonable to do so<br />
[18:41:03] &lt;dannf&gt; any other comments on this?<br />
[18:41:24] &lt;dannf&gt; #agreed kernel: used post-etch rules for fw stripping<br />
<a name='9'></a>
[18:41:40] &lt;dannf&gt; #topic differences between etch/sid 2.6.23 (e.g. config settings)<br />
<a name='10'></a>
[18:42:29] &lt;luk&gt; what are the problems with not changing the config settings?<br />
[18:42:43] &lt;otavio&gt; ata change to pata<br />
[18:42:43] &lt;dannf&gt; last rough consensus on libata was to disable it to make it as easy as possible to switch from .18 to .23 and vice-versa in etch<br />
[18:43:09] &lt;dannf&gt; problem is that we lose sid-testing<br />
[18:43:35] &lt;waldi&gt; libata can't de disables<br />
[18:43:39] &lt;otavio&gt; dannf: didn't get this last part<br />
[18:44:30] &lt;luk&gt; otavio: if 2.6.23 in sid would have libata and 2.6.23 in etch.5 wouldn't...<br />
[18:44:40] &lt;waldi&gt; no<br />
[18:45:29] &lt;dannf&gt; waldi: has that code been ripped out?<br />
[18:45:52] &lt;dannf&gt; or just the config option has disappeared (or am i misunderstanding hte issue?)<br />
[18:46:38] &lt;luk&gt; can libata exist next to the existing ata support in the archive?<br />
[18:47:48] &lt;dannf&gt; (btw, anyone here for the X discussion? if not i'll postpone that for a future meeting)<br />
[18:48:50] &lt;luk&gt; gravity and jcristau not being here, I would postpone the X discussion<br />
[18:49:01] &lt;dannf&gt; ok - well, with 10 minutes left i say we move on to non-kernel stuff, and try and cover libata, etc in a future meeting/mailing list<br />
[18:49:33] &lt;dannf&gt; otavio: you want to spend 5 minutse or so on d-i?<br />
[18:49:47] &lt;dannf&gt; i want to save 5 minutes for "next steps" discussion<br />
[18:49:56] &lt;Sledge&gt; X driver updates would be good, but yeah - not much point discussing without the X folks<br />
[18:50:19] &lt;otavio&gt; dannf: I hadn't yet looked on what would be required on d-i side yet also because we didn't decide all this things about subarches and like<br />
[18:50:38] &lt;otavio&gt; dannf: debian-cd will probably need changes to cope with it too<br />
[18:51:03] &lt;Sledge&gt; yup, probably<br />
[18:51:09] &lt;otavio&gt; dannf: and what worries me is how to test those things in all those arches<br />
[18:51:17] &lt;Sledge&gt; we have an etch branch, will need some update work<br />
[18:51:17] &lt;dannf&gt; otavio: ok, shall we postpone those discussions as well in order to give you guys time to think it over?<br />
[18:51:22] &lt;otavio&gt; Sledge: yes, due new kernel flaours and like<br />
[18:51:31] * Sledge nods otavio <br />
[18:51:41] &lt;otavio&gt; dannf: prefered<br />
[18:51:52] &lt;Sledge&gt; another Q...<br />
[18:51:55] &lt;luk&gt; most things could hopefully be tested in sid...<br />
[18:52:07] &lt;Sledge&gt; would we want some update CDs including d-i that just contain new installer and new packages?<br />
[18:52:08] &lt;otavio&gt; luk: not from d-i side<br />
[18:52:17] &lt;otavio&gt; luk: too different things<br />
[18:52:28] &lt;Sledge&gt; that would be quite some work compared to the normal updates...<br />
[18:52:54] &lt;dannf&gt; Sledge: i'd vote 'not necessary' - but if someone wants to do it, sure<br />
[18:52:57] &lt;otavio&gt; Sledge: other problem will be space restrictions on CD<br />
[18:53:11] &lt;otavio&gt; Sledge: we'll change completely the package set on CDs<br />
[18:53:42] &lt;luk&gt; otavio: I guess we need beta images to test them on all subarchs than<br />
[18:54:57] &lt;dannf&gt; due to shortnesss of time:<br />
[18:54:58] &lt;dannf&gt; #topic gnome/kde updates<br />
<a name='11'></a>
[18:55:33] &lt;dannf&gt; consensus was not to do these in etch 1/2<br />
[18:55:42] * Sledge nods dannf <br />
[18:55:50] &lt;luk&gt; Gnome/KDE was mentioned in Debconf, though the Release Team was thinking about doing them on backports not in etch.5<br />
[18:56:02] &lt;dannf&gt; #agreed kde/gnome will not be updated in etch 1/2<br />
<a name='12'></a>
[18:56:21] &lt;dannf&gt; #topic future discussion<br />
<a name='13'></a>
[18:56:27] &lt;luk&gt; though maybe even announcing them in the same announcement...<br />
[18:56:41] &lt;dannf&gt; i propose we create a teams.debian.net list for future disucssion, so that we don' tneed to cross-post to so many large lists to reach everyone<br />
[18:57:21] &lt;Sledge&gt; sounds like a plan<br />
[18:57:50] &lt;Sledge&gt; anyway...<br />
[18:57:53] * Sledge has to run<br />
[18:57:55] &lt;Sledge&gt; ttfn<br />
[18:57:59] &lt;dannf&gt; ok - i'll setup a list then<br />
[18:58:02] &lt;luk&gt; dannf: ok<br />
[18:58:10] * luk has to leave too ;-)<br />
[18:58:17] &lt;dannf&gt; #agreed teams.debian.net list will be setup for future discussion<br />
<a name='14'></a>
[18:58:41] &lt;dannf&gt; and we can use that list to talk about future meetings<br />
[18:58:43] * pusling was shortly gone - and wouldn't mind relaxed patch acceptance rules for kde.<br />
[18:59:07] &lt;otavio&gt; :-)<br />
[18:59:25] &lt;luk&gt; pusling: unless critical issues, that will probably not work<br />
[18:59:26] &lt;dannf&gt; i'd also like to send a message out to d-d-a - assuming we choose to continue<br />
[18:59:51] &lt;otavio&gt; dannf: difficult to decide now<br />
[18:59:54] &lt;dannf&gt; pusling: i'd say that's more of a topic for the srm team, rather than etch 1/2<br />
[19:00:00] &lt;otavio&gt; dannf: we'll probably need one more meeting, at least<br />
[19:00:00] &lt;pusling&gt; probably<br />
[19:00:04] &lt;luk&gt; pusling: though we hope that KDE will backport the last somewhat stable release to backports for etch.5 :-)<br />
[19:00:06] &lt;tbm&gt; luk: what will etch 1/2 be called?<br />
[19:00:20] &lt;tbm&gt; you said it won't be called etch<br />
[19:00:25] &lt;pusling&gt; luk: the most stable kde in the last year is the one in etch<br />
[19:00:38] &lt;luk&gt; tbm: I guess we still need to decide that<br />
[19:00:42] &lt;dannf&gt; ok - i've gotta run to a meeting, so i suggest we close for now and restart discusions on the teams.d.n list<br />
[19:00:52] &lt;luk&gt; the working title is etch.5 or etch 1/2 ;-)<br />
[19:00:57] &lt;dannf&gt; s/suggest/move/<br />
[19:01:31] &lt;dato&gt; .oO( etchy )<br />
[19:01:34] &lt;dannf&gt; thanks everyone for attending; sorry we didn't make it through everything<br />
[19:01:35] &lt;luk&gt; tnx dannf for chairing the meeting<br />
[19:02:02] &lt;luk&gt; np, we started the discussions and will continue on the list and in other meeting(s)<br />
[19:02:04] &lt;dannf&gt; another release, i think slink, had a slink 1/2 so i stole that scheme<br />
[19:02:16] &lt;tbm&gt; otavio, waldi, luk, can we briefly talk about 2.6.22 and 2.6.23 for sid/testing<br />
[19:02:36] &lt;luk&gt; not at the moment, though I'll read backlog<br />
[19:02:45] &lt;tbm&gt; afaik otavio will make udebs for the current 2.6.2 ABI 3 in a few days<br />
[19:02:45] &lt;tbm&gt; afaik otavio will make udebs for the current 2.6.2 ABI 3 in a few dand it will move to testing<br />
[19:02:48] &lt;otavio&gt; tbm: no problem to me<br />
[19:02:49] * luk is gone now<br />
[19:02:56] &lt;tbm&gt; and waldi is gone too...<br />
[19:03:04] &lt;tbm&gt; never mind then<br />
[19:03:07] &lt;otavio&gt; tbm: you looks right :-)<br />
[19:03:15] &lt;otavio&gt; tbm: that's the plan<br />
[19:03:26] &lt;waldi&gt; tbm: nope<br />
[19:03:39] &lt;otavio&gt; tbm: nop?<br />
[19:04:33] &lt;tbm&gt; ok, I'd like to ask whether we can make one more upload of 2.6.22 (it fixes IP22)<br />
[19:04:38] &lt;tbm&gt; then move that to testing quickly<br />
[19:04:42] &lt;tbm&gt; and then upload 2.6.23<br />
[19:04:58] &lt;tbm&gt; i.e. make udebs of the current version, move it to testing<br />
[19:05:01] &lt;tbm&gt; upload new 2.6.22<br />
[19:05:02] &lt;otavio&gt; tbm: no problem from my side but we'd need to get an ack from ftpmaster for it<br />
[19:05:03] &lt;tbm&gt; udebs/testing<br />
[19:05:05] &lt;tbm&gt; then 2.6.23<br />
[19:05:15] &lt;tbm&gt; otavio: no, it would not have to go through NEW<br />
[19:05:18] &lt;tbm&gt; there's no ABI change<br />
[19:05:28] &lt;otavio&gt; tbm: so fire it<br />
[19:05:37] &lt;waldi&gt; tbm: no. it is not worth the cpu time<br />
[19:05:42] &lt;tbm&gt; well, we have to wait until the current verson hits teting<br />
[19:05:43] &lt;otavio&gt; tbm: at least from me side it would be OK<br />
[19:05:51] &lt;tbm&gt; waldi: there's also a new stable release for 2.6.22 pending<br />
[19:05:54] &lt;tbm&gt; that's worth having<br />
[19:06:00] &lt;waldi&gt; tbm: no, .23 is waiting<br />
[19:06:14] &lt;otavio&gt; waldi: sorry but I ack with tbm here<br />
[19:06:39] &lt;otavio&gt; waldi: it's going to be use for beta d-i release, probably, and then we ought to try to give it much love as possible<br />
[19:06:58] &lt;otavio&gt; waldi: and a upload with urgency medium won't hurt<br />
[19:07:11] &lt;h01ger&gt; otavio: for importance the date (the more early) matters more than the higher kernel version. <br />
[19:07:12] &lt;h01ger&gt; Md: upgrades from .18 to lenny must work too :)<br />
[19:07:30] * h01ger arrived some minutes ago and has just fineshed reading backlog :)<br />
[19:07:57] &lt;otavio&gt; h01ger: sorry, didn't get<br />
[19:08:09] &lt;h01ger&gt; dannf, you need to say #endmeeting to stop the bot collecting logs <br />
Meeting ended.<br />