20:07:59 #startmeeting 20:07:59 Meeting started Mon Oct 5 20:07:59 2009 UTC. The chair is otavio. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:07:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:08:17 Well; let's start a mini meeting since few people is around 20:08:32 Please people, wave ... this time for it to be recorded 20:08:35 * otavio 20:08:40 * otavio waves 20:08:43 * fezie waves 20:08:44 * luk_ waves 20:10:04 Ok 20:10:17 #topic Current release status 20:10:42 Before we start discussion other stuff I'd like to talk about our current, and late, release 20:11:01 I did the mass-upload of the kernel udebs 20:11:45 I'd like to have an idea from RM people (luk) about when they believe linux-2.6 would be ready to go to squeeze? 20:13:16 it's about ready to transition AFAIK 20:14:41 luk_: In this case ... when we could plan to make it happen? 20:15:06 it will probably happen today or tomorrow 20:15:15 luk_: OK 20:15:32 luk_: in this case I'd try to push installer to be build once it is done 20:15:48 ok 20:15:50 luk_: today after work I'll check what is still missing and try to report back to you 20:16:24 ok, maybe we need some more udebs transitioned... 20:16:31 luk_: yes; probably 20:16:41 libdebian-installer comes to my mind 20:16:46 but probably others too 20:17:08 should I already unblock that one? 20:17:40 luk_: sure; no problem 20:17:49 luk_: and grub-installer and os-prober as well 20:18:09 os-prober migrated lately is it uploaded again? 20:18:28 * otavio will look 20:19:13 should I age-days grub-installer (it's at 5 days out of 10)? 20:19:40 luk_: no; it has not been uploaded 20:19:52 luk_: well, we might coordinate it after meeting. Could be? 20:19:57 sure 20:20:24 * luk_ hopes for a short meeting :-) 20:20:26 testing currently has grub-installer 1.36 which is pretty old 20:20:45 the bits currently in svn aren't critical, imo 20:21:02 cjwatson: but current sid one is right? 20:21:04 well, the grub2 maintainers might like to have that --force change, but it's not the end of the world 20:21:11 I could also age-days the current one, which would get in today... 20:21:15 we should definitely have 1.46 (in unstable) though 20:21:38 cjwatson: so maybe you might push and upload it? and then we get it aged for us? 20:21:41 and would leave the option of uploading another version 20:22:32 even though, grub-installer is not critical for now since it is not in initr 20:22:35 initrd 20:22:48 otavio: I'd rather 1.46 got in first, TBH 20:23:14 cjwatson: can be 20:23:50 * otavio warns that is raining here so eletrical issues can happen heh 20:24:39 I don't associate raining with possible electrical issues, though maybe that's just because I don't know the context 20:24:58 luk_: it is more like a thunderstorm here 20:25:15 anyway, if you want me to age-days grub-installer so 1.46 would make testing first, please tell me 20:25:38 luk_: please do 20:25:56 done 20:26:18 ok, what other items are still outstanding? 20:26:56 regarding the alpha release 20:27:23 should there be sent a time planning to the list? 20:27:52 are there any remaining blockers? 20:28:03 I'll look at build failures today and take care of them 20:28:14 Then I'll coordinate what is missing with you and then we can plan on that 20:28:19 you == luk 20:28:23 ok, great 20:29:52 Do anyone wants a speicifc topic? 20:30:09 the one about the kernel udebs 20:30:09 From my POV the current status and next steps are covered 20:30:22 #topic Kernel udebs merging into linux-2.6 20:30:31 luk_: start please 20:31:04 AFAIK for all packages except for the kernel (and modules), the udebs are integrated in the main packages 20:31:51 AFAICT for the kernel package there was decided to not include them in the main package as out of sync rebuilds where useful 20:32:20 AFAICS there were also non technical reasons to not include them in the kernel package 20:32:25 Yes; they're specially during deep changes in kernel 20:33:03 how would having them built within the kernel package not be enough? 20:33:06 we moved the kernel udebs into the main kernel package in Ubuntu a while back, and I have to say that my experiences with that have not been particularly good 20:33:25 cjwatson: please explain the issues 20:34:34 the problems have been that (a) the kernel team have had to figure out how the installer is laid out, and it's not really something they care about all that deeply (b) it's the installer team who get bugs when the kernel udebs are laid out wrongly, and now we can't fix them directly (c) every so often the kernel team decides to reorganise udebs and then the installer team has to scratch their heads trying to figure out how ... 20:34:41 ... to get the installer to work properly again (since the kernel udeb layout is very carefully designed around how the installer works) 20:35:18 hmm, that seems very strange compared to other packages 20:35:21 the kernel udeb layout inherently straddles the kernel and installer teams, and it's awkward 20:35:33 I'm not saying it can't work in Debian 20:35:48 but, if you do it, I strongly advise ensuring that the installer team can commit directly to the files that control the kernel udeb layout 20:35:57 since it is really very closely tied to the installer build system 20:36:17 you don't have to listen, just my advice from bitter experience :) 20:36:20 AFAICS for most packages the packager expect the installer team to still have control to change the udebs (and their layout) 20:36:56 I do think that having that changed is not what we want nor what should be tried 20:36:59 most packages that are as tightly integrated into the installer as kernel udebs are, are maintained by the installer team directly 20:37:02 as in, in d-i svn 20:37:25 the ones that aren't are mostly just collections of binaries and things, so the integration isn't really all that tight or complex 20:38:12 besides; most of them do not change as much as kernel 20:38:14 ;-) 20:38:21 on the other hand, of course the kernel udebs do have to be changed in step with the kernel sometimes, and I know that there are lots of fun archive issues with them being separate 20:38:41 this is really just a warning that there are issues either way and you shouldn't ignore the ones you're stepping into 20:38:54 right, let me explain the reasons why having them in the kernel package is a good thing from archive and release point of view: 20:39:26 cjwatson: yes; this shares most of my concerns about getting them merged into linux-* sources 20:39:32 (personally I do understand the pros and am not trying to argue they don't exist) 20:39:44 when a new kernel gets built, it's not guaranteed that the udebs are also rebuilt 20:40:02 this means there has to be a means to know which udebs belong to which source 20:40:09 this is not the case atm 20:40:46 when a kernel migrates to testing, the udebs don't necessarily migrate together with it 20:41:06 this means that whatever was needed to migrate the kernel will have to be redone with the udebs 20:41:38 that can involve quite some hinting and/or removing from modules 20:42:05 the end result might not be the same and might cause the same archive concerns as the ones that exist in unstable 20:42:06 however, specially with deep changes we avoid breaking installer for too long since we can do local builds and test them before moving to the new kernel code 20:42:16 * bubulle just pops up.... luk_ probably did not remember that I announced I couldn't be around (even if I was back home from K� I had other commitments tonight) 20:42:32 and now I have a commitment with my bed...:-) 20:42:55 bubulle: heh 20:43:11 otavio: that's only an argument to keep kernel-wedge and do tests AFAICS 20:43:12 luk_: right, that I understand - just making sure people are warned that it raises some interesting and potentially painful maintenance concerns 20:44:44 I would like to avoid these maintenance concerns as much as possible by having d-i access to the kernel vcs and the intent to coordinate on uploads the pre-conditions of the move to the kernel package 20:44:57 luk_: with the usual problems we had with kernel team (and this has improved A LOT since release) I fear to move it there 20:45:03 luk_: that would help a lot, yes 20:45:28 I personally want to help out if there would be problems between the teams 20:45:31 luk_: we'd need to be able to have some kind of control, inside of kernel team, about udebs and like 20:45:38 yes 20:46:08 luk_: and also be able to raise the urgency of uploads in case of installer requirements, brokeness and like 20:46:27 indeed, coordination on uploads from both sides 20:46:58 luk_: yes but it never happened (except this last upload that was announced and coordinated with Ben) 20:47:18 luk_: so this worries me a lot 20:47:19 I do think that the kernel team is willing to cooperate when it would make coordinating for testing migration and d-i releases easier 20:47:45 there are wrong assumptions on both sides 20:47:56 luk_: to it to be considered we'd need to have them around and we all agree in a way to work tovarlds this 20:48:22 luk_: mostly because it affects both teams 20:48:29 sure, this is just in the preliminary phase, there indeed needs to be some discussion with the teams together 20:48:52 luk_: for example, they do not follow installation reports even though 90% of failures and problems are kernel issus 20:48:55 issues 20:49:45 they have hundreds and hundreds of bugs to look after, it's not so black and white believe me 20:50:39 we will probably not be able to just solve the installation reports problem, but it is certainly a good idea to make them more aware of them 20:51:02 luk_: sure; I know that. 20:51:07 mm, to be fair most of us fail to follow installation reports too (also hundreds and hundreds of bugs ...) 20:51:46 luk_: however moving directly to new kernel will put a much higher pressure above us; since we'll get directly affected by the "new issues" 20:51:55 cjwatson: yes; fully agree 20:53:16 luk_: currently, we have a period of time that allow us to wait until kernel is somewhat stabilized and then put it in installer 20:53:19 luk_: we'd lose it 20:54:34 2.6.31 is in experimental now to make sure it can be stabilised before upload to unstable... 20:55:01 luk_: this is a very nice improvement 20:55:02 luk_: indeed 20:55:29 luk_: but as I said, I think that we need to sit all together and talk about how would it work 20:55:46 luk_: so we'd need to get kernel team around to discuss it 20:56:25 debian-installer: 03aurel32 * r60937 10installer/build/config/kfreebsd.cfg: Add handler.mod to the list of grub modules for GNU/kFreeBSD 20:56:26 indeed 20:56:42 aurel32 is around, but hiding :-) 20:57:10 should we try to setup a separate meeting to discuss this between the kernel and d-i teams? 20:57:12 luk_: I think most of them (maks, waidi, ben, aurel, ...) need to be around for it 20:57:31 luk_: i guess it might be interested 20:57:36 luk_: interesting 20:57:54 luk_: but I do believe that the best way is to them to write a small proposal about it to the ml 20:58:10 luk_: this way we can all sit and think about it more carefully 20:58:57 I think a mail from me to both lists with some more info and a pointer to a doodle might be a good idea? 20:59:06 you were looking at me? 20:59:19 * aurel32 is hiding behing a 3G modem 20:59:32 working in 2G because the place is too crappy 20:59:41 aurel32: poor you 20:59:44 not in particular, just strange that you committed something in the middle of the meeting when you did not mention you were here 21:00:36 luk_: I'd really prefer that what they believe as general lines might be posted before 21:01:18 otavio: so you want a mail discussion before? 21:01:27 luk_: I think it is better 21:01:42 luk_: it allows for better thinking about pros and cons 21:02:09 and for more opportunity to misinterpret AFAICT 21:02:19 without being aware soon 21:03:10 directly to new kernel> IMO that's a good thing to do in unstable - speeds up the feedback loop for the kernel 21:06:24 thunderstorm? 21:06:52 debian-installer: 03aurel32 07d-i * r60938 10/kfreebsd/ (285 files in 104 dirs): Merge from trunk, revision 60839 to 60937 21:07:03 my connection has fall 21:07:08 I'm back 21:07:10 :( 21:08:26 otavio: I do think that having the kernel udebs in the kernel package might be good for everyone, I'm not very fond of having a proposal from the kernel team to shoot at 21:08:38 22:03 directly to new kernel> IMO that's a good thing to do in unstable - speeds up the feedback loop for the kernel 21:08:45 (in case otavio missed that) 21:08:56 cjwatson: thx 21:09:06 luk_: might be 21:09:17 luk_: ok; so let's try an alternative route ... 21:10:02 luk_: you and me talk to kernel team, at first moment, and then we prepare a general idea to be posted into the mailing list for further discussion 21:11:25 ok 21:11:34 what people think? 21:11:45 this way we avoid too many problems I think 21:13:16 right 21:15:26 Next topic/ 21:15:27 ? 21:16:14 I would not mind closing up so we can have a look at the release preparations 21:16:37 So if no one objects, I'm closing the meeting 21:17:17 #endmeeting