20:07:59 <otavio> #startmeeting
20:07:59 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:08:17 <otavio> Well; let's start a mini meeting since few people is around
20:08:32 <otavio> 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 <otavio> Ok
20:10:17 <otavio> #topic Current release status
20:10:42 <otavio> Before we start discussion other stuff I'd like to talk about our current, and late, release
20:11:01 <otavio> I did the mass-upload of the kernel udebs
20:11:45 <otavio> 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 <luk_> it's about ready to transition AFAIK
20:14:41 <otavio> luk_: In this case ... when we could plan to make it happen?
20:15:06 <luk_> it will probably happen today or tomorrow
20:15:15 <otavio> luk_: OK
20:15:32 <otavio> luk_: in this case I'd try to push installer to be build once it is done
20:15:48 <luk_> ok
20:15:50 <otavio> luk_: today after work I'll check what is still missing and try to report back to you
20:16:24 <luk_> ok, maybe we need some more udebs transitioned...
20:16:31 <otavio> luk_: yes; probably
20:16:41 <otavio> libdebian-installer comes to my mind
20:16:46 <otavio> but probably others too
20:17:08 <luk_> should I already unblock that one?
20:17:40 <otavio> luk_: sure; no problem
20:17:49 <otavio> luk_: and grub-installer and os-prober as well
20:18:09 <luk_> os-prober migrated lately is it uploaded again?
20:18:28 * otavio will look
20:19:13 <luk_> should I age-days grub-installer (it's at 5 days out of 10)?
20:19:40 <otavio> luk_: no; it has not been uploaded
20:19:52 <otavio> luk_: well, we might coordinate it after meeting. Could be?
20:19:57 <luk_> sure
20:20:24 * luk_ hopes for a short meeting :-)
20:20:26 <cjwatson> testing currently has grub-installer 1.36 which is pretty old
20:20:45 <cjwatson> the bits currently in svn aren't critical, imo
20:21:02 <otavio> cjwatson: but current sid one is right?
20:21:04 <cjwatson> well, the grub2 maintainers might like to have that --force change, but it's not the end of the world
20:21:11 <luk_> I could also age-days the current one, which would get in today...
20:21:15 <cjwatson> we should definitely have 1.46 (in unstable) though
20:21:38 <otavio> cjwatson: so maybe you might push and upload it? and then we get it aged for us?
20:21:41 <luk_> and would leave the option of uploading another version
20:22:32 <otavio> even  though, grub-installer is not critical for now since it is not in initr
20:22:35 <otavio> initrd
20:22:48 <cjwatson> otavio: I'd rather 1.46 got in first, TBH
20:23:14 <otavio> cjwatson: can be
20:23:50 * otavio warns that is raining here so eletrical issues can happen heh
20:24:39 <luk_> I don't associate raining with possible electrical issues, though maybe that's just because I don't know the context
20:24:58 <otavio> luk_: it is more like a thunderstorm here
20:25:15 <luk_> anyway, if you want me to age-days grub-installer so 1.46 would make testing first, please tell me
20:25:38 <otavio> luk_: please do
20:25:56 <luk_> done
20:26:18 <luk_> ok, what other items are still outstanding?
20:26:56 <luk_> regarding the alpha release
20:27:23 <luk_> should there be sent a time planning to the list?
20:27:52 <luk_> are there any remaining blockers?
20:28:03 <otavio> I'll look at build failures today and take care of them
20:28:14 <otavio> Then I'll coordinate what is missing with you and then we can plan on that
20:28:19 <otavio> you == luk
20:28:23 <luk_> ok, great
20:29:52 <otavio> Do anyone wants  a speicifc topic?
20:30:09 <luk_> the one about the kernel udebs
20:30:09 <otavio> From my POV the current  status and next steps are covered
20:30:22 <otavio> #topic Kernel udebs merging into linux-2.6
20:30:31 <otavio> luk_: start please
20:31:04 <luk_> AFAIK for all packages except for the kernel (and modules), the udebs are integrated in the main packages
20:31:51 <luk_> 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 <luk_> AFAICS there were also non technical reasons to not include them in the kernel package
20:32:25 <otavio> Yes; they're specially during deep changes in kernel
20:33:03 <luk_> how would having them built within the kernel package not be enough?
20:33:06 <cjwatson> 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 <luk_> cjwatson: please explain the issues
20:34:34 <cjwatson> 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 <cjwatson> ... 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 <luk_> hmm, that seems very strange compared to other packages
20:35:21 <cjwatson> the kernel udeb layout inherently straddles the kernel and installer teams, and it's awkward
20:35:33 <cjwatson> I'm not saying it can't work in Debian
20:35:48 <cjwatson> 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 <cjwatson> since it is really very closely tied to the installer build system
20:36:17 <cjwatson> you don't have to listen, just my advice from bitter experience :)
20:36:20 <luk_> AFAICS for most packages the packager expect the installer team to still have control to change the udebs (and their layout)
20:36:56 <luk_> I do think that having that changed is not what we want nor what should be tried
20:36:59 <cjwatson> most packages that are as tightly integrated into the installer as kernel udebs are, are maintained by the installer team directly
20:37:02 <cjwatson> as in, in d-i svn
20:37:25 <cjwatson> 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 <otavio> besides; most of them do not change as much as kernel
20:38:14 <otavio> ;-)
20:38:21 <cjwatson> 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 <cjwatson> 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 <luk_> 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 <otavio> cjwatson: yes; this shares most of my concerns about getting them merged into linux-* sources
20:39:32 <cjwatson> (personally I do understand the pros and am not trying to argue they don't exist)
20:39:44 <luk_> when a new kernel gets built, it's not guaranteed that the udebs are also rebuilt
20:40:02 <luk_> this means there has to be a means to know which udebs belong to which source
20:40:09 <luk_> this is not the case atm
20:40:46 <luk_> when a kernel migrates to testing, the udebs don't necessarily migrate together with it
20:41:06 <luk_> this means that whatever was needed to migrate the kernel will have to be redone with the udebs
20:41:38 <luk_> that can involve quite some hinting and/or removing from modules
20:42:05 <luk_> 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 <otavio> 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 <bubulle> and now I have a commitment with my bed...:-)
20:42:55 <otavio> bubulle: heh
20:43:11 <luk_> otavio: that's only an argument to keep kernel-wedge and do tests AFAICS
20:43:12 <cjwatson> luk_: right, that I understand - just making sure people are warned that it raises some interesting and potentially painful maintenance concerns
20:44:44 <luk_> 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 <otavio> 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 <cjwatson> luk_: that would help a lot, yes
20:45:28 <luk_> I personally want to help out if there would be problems between the teams
20:45:31 <otavio> luk_: we'd need to be able to have some kind of control, inside of kernel team, about udebs and like
20:45:38 <luk_> yes
20:46:08 <otavio> luk_: and also be able to raise the urgency of uploads in case of installer requirements, brokeness and like
20:46:27 <luk_> indeed, coordination on uploads from both sides
20:46:58 <otavio> luk_: yes but it never happened (except this last upload that was announced and coordinated with Ben)
20:47:18 <otavio> luk_: so this worries me a lot
20:47:19 <luk_> 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 <luk_> there are wrong assumptions on both sides
20:47:56 <otavio> 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 <otavio> luk_: mostly because it affects both teams
20:48:29 <luk_> sure, this is just in the preliminary phase, there indeed needs to be some discussion with the teams together
20:48:52 <otavio> luk_: for example, they do not follow installation reports even though 90% of failures and problems are kernel issus
20:48:55 <otavio> issues
20:49:45 <luk_> they have hundreds and hundreds of bugs to look after, it's not so black and white believe me
20:50:39 <luk_> 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 <otavio> luk_: sure; I know that.
20:51:07 <cjwatson> mm, to be fair most of us fail to follow installation reports too (also hundreds and hundreds of bugs ...)
20:51:46 <otavio> 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 <otavio> cjwatson: yes; fully agree
20:53:16 <otavio> 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 <otavio> luk_: we'd lose it
20:54:34 <luk_> 2.6.31 is in experimental now to make sure it can be stabilised before upload to unstable...
20:55:01 <otavio> luk_: this is a very nice improvement
20:55:02 <otavio> luk_: indeed
20:55:29 <otavio> luk_: but as I said, I think that we need to sit all together and talk about how would it work
20:55:46 <otavio> luk_: so we'd need to get kernel team around to discuss it
20:56:25 <CIA-6> debian-installer: 03aurel32 * r60937 10installer/build/config/kfreebsd.cfg: Add handler.mod to the list of grub modules for GNU/kFreeBSD
20:56:26 <luk_> indeed
20:56:42 <luk_> aurel32 is around, but hiding :-)
20:57:10 <luk_> should we try to setup a separate meeting to discuss this between the kernel and d-i teams?
20:57:12 <otavio> luk_: I think most of them (maks, waidi, ben, aurel, ...) need to be around for it
20:57:31 <otavio> luk_: i guess  it might be interested
20:57:36 <otavio> luk_: interesting
20:57:54 <otavio> 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 <otavio> luk_: this way we can all sit and think about it more carefully
20:58:57 <luk_> 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 <aurel32> you were looking at me?
20:59:19 * aurel32 is hiding behing a 3G modem
20:59:32 <aurel32> working in 2G because the place is too crappy
20:59:41 <otavio> aurel32: poor you
20:59:44 <luk_> 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 <otavio> luk_: I'd really prefer that what they believe as general lines might be posted before
21:01:18 <luk_> otavio: so you want a mail discussion before?
21:01:27 <otavio> luk_: I think it is better
21:01:42 <otavio> luk_: it allows for better thinking about pros and cons
21:02:09 <luk_> and for more opportunity to misinterpret AFAICT
21:02:19 <luk_> without being aware soon
21:03:10 <cjwatson> 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 <luk_> thunderstorm?
21:06:52 <CIA-6> debian-installer: 03aurel32 07d-i * r60938 10/kfreebsd/ (285 files in 104 dirs): Merge from trunk, revision 60839 to 60937
21:07:03 <otavio> my connection has fall
21:07:08 <otavio> I'm back
21:07:10 <otavio> :(
21:08:26 <luk_> 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 <cjwatson> 22:03 <cjwatson> 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 <cjwatson> (in case otavio missed that)
21:08:56 <otavio> cjwatson: thx
21:09:06 <otavio> luk_: might be
21:09:17 <otavio> luk_: ok; so let's try an alternative route ...
21:10:02 <otavio> 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 <luk_> ok
21:11:34 <otavio> what  people think?
21:11:45 <otavio> this way we avoid too many problems I think
21:13:16 <luk_> right
21:15:26 <otavio> Next topic/
21:15:27 <otavio> ?
21:16:14 <luk_> I would not mind closing up so we can have a look at the release preparations
21:16:37 <otavio> So if no one objects, I'm closing the meeting
21:17:17 <otavio> #endmeeting