People who speak below:

bouz      : Denis Barbier
bubulle   : Christian Perrier
dannf     : Dan Frazier
eugen     : Eugeniy Meshcheryakov
fjp       : Frans Pop
jbailey   : Jeff Bailey
joeyh     : Joey Hess
jvw       : Jeroen van Wolffelaar
JW        : Jouke Witteveen
Kamion    : Colin Watson
kmuto     : Kenshi Muto
makx      : Maximilian Attems
noshadow  : Bernhard R. Link
otavio    : Otavio Salvador
p2-mate   : Peter de Shrijver
pere      : Petter Reinholdtsen
Q_        : Kurt Roeckx
ths       : Thiemo Seufer
trave11er : Jurij Smakov
vorlon    : Steve Langasek

Hours are European Time (UTC +0200):


16:00 < bubulle> time...:-)
16:00 < bubulle> So let's open the third D-I meeting I'a aware of..:-)
16:00 < bubulle> Is someone logging (I am anyway)?
16:01 < bubulle> First topic : 
16:01 < bubulle> d-i release management
16:01 < bubulle> joey mentioned he wants to slowly drop the load of d-i release management
16:01 < bubulle> so we have two things two discuss : volunteers and a first target for en etch installer release (sarge release management is the 2nd topic)
16:01 < bubulle> joey...?
16:01 < joeyh> ok.
16:02 < joeyh> first, an announcement -- fjp has agreed to be a release assistant for the next d-i beta, and to manage the one after that
16:02 < bubulle> everyone was expecting this..:-)
16:02 < makx> congrats fjp!
16:02 < joeyh> so he'll be cced on anything I do and will be taking on some of it too
16:02 < kmuto> excellent :)
16:02  * fjp can't remember anything about the second part ;-)
16:02 < joeyh> :-P
16:03 < bubulle> IMHO, the duty of other ppl is not leave the two of you alone doing so
16:03 < joeyh> so, I think that we should shoot for a release fairly soon (but not before debconf or anything like that). We have enough post sarge features to make it worthwhile
16:03 < joeyh> - new kernels , - rescue mode , etc
16:04  * bubulle agrees
16:04 < Kamion> yep
16:04 < bubulle> do we actually have cd images builds working?
16:04 < pere> To make sure the sarge release stays relevant for as long as possible, we should try to make sure it include updated drivers for hardware released after the initial release.  new kernels, X and discover/hotplug is needed.
16:04 < joeyh> also most of the arches might not have broken yet, if we're lucky..
16:04 < Kamion> we'll need to try to get new kernels in on a few more architectures
16:04  * vorlon moos in a somewhat tardy fashion
16:04 < joeyh> CD image builds are not yet running for etch
16:05 < CIA-1> debian-installer: sleblanc-guest * r28504 packages/po/eo.po: korektoj kaj tradukoj
16:05 < joeyh> of course, debootstrap is also broken (unless aj fixed it last night)
16:05 < fjp> And there is one unsolved mystery with debootstrap
16:05 < bubulle> joeyh: so this should be an immediate target : have the CD builds work ?
16:06 < Kamion> are the CD image builds basically just waiting for the -cd team to recover from the release party hangover?
16:06 < joeyh> bubulle: manty was talking about a "week of rest" and then getting it going
16:06 < bubulle> Can we target something like end of July for a first release?
16:06 < joeyh> I think his week is close to up
16:06 < Kamion> I'll be seeing Steve McIntyre tonight, will poke
16:06 < fjp> What do we mean by new kernels: 2.6.8 updates for Sarge or 2.6.11 for Etch?
16:06 < fjp> (or both)
16:06 < joeyh> something in that area seems doable
16:06 < bubulle> fjp: these are others topics..:-)
16:06 < Kamion> fjp: I was referring to the latter, but both really
16:06 < bubulle> see topics list..:)
16:07 < joeyh> well, I was talking about etch, but yes, both
16:07 < pere> fjp: I do not care about the version number for sarge, but we need to put kernels in sarge/d-i capable of handling new hardware.  at the end of the woody release, it was unable to install on lots of new servers.
16:07 < bubulle> OK, so let's say end of July for a first target of an etch installer
16:07 < joeyh> oh yeah, possibly a graphical version of the installer too..
16:07 < JW> why?
16:07 < fjp> Would be nice to have that in teh dailies at least
16:07  * bubulle proposes that the real content of the first etch installer is discussed in another (close) mùeeting
16:08 < bubulle> something just before the d-i camp at debconf. Would that be OK and leave fjp/joeyh some time to prepare a release plan?
16:08 < JW> I followed the development of a graphical installer and regret it a bit. I breaks compatibility and speed to a certain level. Why not split D-I into multiple branches?
16:09 < Kamion> I'd like it if we had a few general ideas, possibly after disposing of the rest of the content of this meeting
16:09 < Kamion> JW: it would never be mandatory.
16:09 < joeyh> I expect we'll make improvements at debconf that will need to be taken into account after
16:09 < bubulle> OK, then after the meeting...just to be sure that we deal with other issues first..:-)
16:09 < bubulle> So, second topic, folks
16:09 < JW> no, I understand. But at this moment the Woody installer works better for me than the one of Sarge...
16:09 < JW> okay
16:09 < bubulle> sarge branch maintenance and sarge point release management
16:10 < Kamion> JW: let's discuss this *after* the meeting, please. we have an agenda and some people are time-constrained.
16:10 < bubulle> we need to try setting up a sarge "point" releases schedule
16:10 < JW> yes. okay Kamion
16:10 < bubulle> and we probably need some sarge installer point release managers..:-)
16:10 < Kamion> I may be able to help there
16:11 < Kamion> of course the amount of effort involved kind of depends whether we're sticking with 2.6.8 or going with something newer
16:11  * bubulle feels that a sarge installer "point" release is needed quite soon (mostly for hardware problems : SATA and stuff)
16:11 < joeyh> big question here about sarge is, do we want to only do d-i releases that incorporate errata fixes, kernel security holes, etc; or do we want to also make releases supporting installing sarge with eg, new kernels from etch, the etch installer, etc?
16:11  * pere is not volunteering, but believe we need to have a system to get updated packages (kernel/X) into sarge/main, and not expect volatile to be the rescue mode when trying to support newer hardware in the future.
16:12 < bubulle> we probably need more than errata fixes and sec holes fixes
16:12 < joeyh> we can do both, it's probably easier to get only the more "traditional" updates into sarge.
16:13 < Kamion> thing is, new kernels are going to require a bit more than just the installer - if you're using 2.6.11 you need rootskel and base-config updates to make the framebuffer work properly, frex
16:13 < pere> bubulle: I agree.  we need to add new features to d-i in sarge, when they are well tested in etch.
16:13 < bubulle> pere: I'm not sure about all features
16:13 < joeyh> well backporting individual features could be a lot of work
16:13 < pere> bubulle: not all features, but the good ones. :)
16:13 < bubulle> the corner stone seems to be hardware support
16:13 < vorlon> if someone's planning for newer-than-2.6.8 kernels for sarge, that'll be coordinated with Joey, I hope?
16:13 < bubulle> vorlon: yep. I hopedhe would attend but he excused self
16:14 < joeyh> we could make sure to keep etch d-i capale of installing sarge, but that still has the problem of where it gets new kernel debs from, etc
16:14 < Kamion> I think any sarge updates have to be coordinated with Joey, unless they're done in some separate repository ...
16:14 < pere> debian-edu ran into the wall with woodys kernel after ~1 year.  then we needed to provide upgraded kernels to get it to work on new hw.
16:14 < vorlon> I would definitely like to see 3.1r1 include matching kernel debs and udebs again
16:14 < Kamion> I'm a bit concerned about attempting to use etch's kernel for the installer and install the kernels currently in sarge
16:14 < Kamion> I think that's going to run into hardware detection hell down the line#
16:14 < joeyh> Kamion: yes, doesn't really fly, we need to use and install same kernel
16:15 < fjp> That would probably cause reboot problems.
16:15 < bubulle> Kamion: given the current SATA nightmare, isn't that our only solution?
16:15 < Kamion> the SATA nightmare is certainly a nasty hard problem
16:15 < Kamion> I'm not even necessarily convinced that just moving to .11 is sufficient
16:16 < bubulle> Up to now, I heard about Kamion volunteering for sarge installer release management (if there are some) and that's all
16:16 < Kamion> it may take hw-detect ordering tweaks as well
16:16 < fjp> Another option is to point ppl with SATA problems to the Etch installer and have them run Etch instead of Sarge.
16:16 < pere> .11 have audio problems, at least on my thinkpad x30, so I suspect it is not a good replacement.
16:16 < trave11er> Kamion: fwiw, 2.6.11 mini.iso seems to detect sata disks just fine
16:16 < Kamion> trave11er: ok, but my experience has been that it varies a lot between chipsets
16:16 < vorlon> pere: seconded; it craps on my Dell laptop as well
16:16 < makx> pere: etch won't release with 2.6.11, we are already working on 2.6.12
16:16 < trave11er> Kamion: yeah, i don't have a loot of information
16:17 < joeyh> maybe joey won't mind letting new kernel packages into sarge, it's just an added package after all, nothing changed.
16:17  * dannf notes that it'll become more difficult to use post-2.6.11 kernels as the kernel team is planning to switch to the unified source soon, and rumor is devfs is being dropped upstream
16:17 < vorlon> makx: but doesn't 2.6.12 give us devfs problems?  or i that 2.6.13?
16:17 < joeyh> wouldn't hurt to ask
16:17  * pere is not really up to date, but find it hard to see which kernel issues are open or not when using BTS.
16:17 < makx> vorlon: 2.6.13 will dropp devfs, yes indeed.
16:17 < joeyh> dannf: not just rumour, the patch exists and is scheduled afaik
16:17 < fjp> dannf: I saw that too. Planned for July
16:17 < Kamion> switching to udev does seem rather too big a change for sarge, although we've got to take care of it in etch
16:18 < bubulle> So (sorry to hurry you up a bit but I think we need to go forward), it seems all this needs a specialized talk with Joey and probably the kernel team, right?
16:18 < vorlon> right, so there's no sane way to have an official sarge d-i that uses a kernel > 2.6.12
16:18 < pere> how hard is it to switch to udev?  can we teach it to created devfs-like paths?
16:18 < Kamion> pere: already done
16:18 < pere> so, what is the problem?
16:18 < Kamion> pere: Ubuntu 5.04 does exactly that. However, lots of stuff broke in the process; there are a number of subtle behaviour differences
16:19 < pere> hrumf.
16:19 < Kamion> I've caught and committed fixes for everything I could, but I'm sure I missed some stuff
16:19 < Kamion> plus I've never tried it without hotplug
16:19 < bubulle> Well, second topics seems somewhat closed : no real conclusion, but Kamion mentioning interest..:-)
16:19  * pere believed most device-handling code was limited to partitioning and grub.
16:19 < bubulle> Let's move on if you agree. something to add?
16:19 < Kamion> bubulle: you're right we need to talk with Joey about the range of stuff that could be acceptable
16:20 < Kamion> pere: hardware detection, os-prober, all the other bootloaders, prebaseconfig, rootskel, random other stuff
16:20  * pere belive we need to convince the stable release manager to relax his acceptance rules, and perhaps help him with the work load.
16:20 < bubulle> OK, note to self : arrange something with Joey and part of the d-i team
16:21 < Kamion> for SATA I'm beginning to warm to fjp's option, if we can keep etch stableish
16:21 < bubulle> pere: and probably raise some of his concerns with the Vancouver proposal people, I'm afraid...:-|
16:21 < bubulle> anyway, let's move
16:21 < bubulle> Third topic:
16:21 < bubulle> how to get development ramped back up and attract and re-attact more developers
16:21 < bubulle> We are not so many people working on d-i currently. Is this a problem?
16:22 < pere> daily snapshot releases, and test release announcements, That is the way to go. :)
16:22 < bubulle> one point seems to not forget improving what's currently done and not only add features..:-)
16:22 < joeyh> there's a bit of a lack of active developers for some arches..
16:22 < bubulle> the bug log of all D-I packages is HUGE
16:22 < vorlon> pere: a good start in that direction would probably be if the kernel team would show they're capable of providing security-fixed kernel images across all architectures in a timely manner...
16:22 < vorlon> (hasn't happened yet, and there are a number of archs the kernel team doesn't even cover)
16:22 < Kamion> I got sucked in in the days of beta2 or so, when there were frequent test release announcements saying "and we really need help on these things, here's how you can help, <recipe>, look, it's not that hard really"
16:23 < joeyh> right, and there will be a talk at debconf that features some of that
16:23 < pere> Kamion: exactly.  I'm sure there are clueful people looking for a place to start.
16:23 < joeyh> I've thought about also doing a d-d-a post with some of those
16:23 < ths> For mips I'm currently trying to get 2.6.12 reasonably in shape, thus no time for d-i so far.
16:23 < bubulle> joeyh: do you think it'd worth spamming all people who currently have commit access to SVN?
16:23 < Kamion> yeah, we have to remember that there's the hurdle of "but I don't have any spare machines!" and a number of established ways to do development nonetheless
16:24 < pere> joeyh: plan a sequence of annoucement to d-d-a, a few features at the time. :)
16:24 < joeyh> (see installer/doc/talks/d-i_debconf5/d-i_debconf5.xml)
16:24 < bubulle> there are about 120 of them, IIRC
16:24 < pere> bubulle: at least the developers.  perhaps not all the translators?
16:24 < fjp> We should also get an idea if people who worked actively on an area in the past are willing to continue or if we should look for replacement. Maybe do a mail round?
16:24 < eugen> bubulle: how many of them are translators?
16:24 < joeyh> Kamion: well, there is the d-i lab, which can take remote users now
16:24 < Kamion> it can? nifty
16:25 < joeyh> bubulle: spam them with what?
16:25 < bubulle> eugen, pere: dunno how many are translators...maybe helf
16:25  * pere want to reduce is d-i involvement, and focus mostly on hw detection.
16:25 < bubulle> joeyh: just a mail mentioning that we want the d-i devel to be pushed again and we probably need them
16:26 < joeyh> no need to ask the translators, you already do that afaics
16:26 < fjp> bubulle: I think it should focus on key people for components that seem currently inactive
16:26 < joeyh> personalised mails will probably work better
16:26 < bubulle> we have another problem i Feel : who is in charge of what....
16:26 < pere> bubulle: or perhaps look at the uploaders list for udebs?
16:26 < JW> I think getting new developpers can be a problem. Since software gets better all the time fewer people are interested in how it works anymore. I forsee that the future does not bring a solution. Perhaps its a solution to introduce a sort of hierarchy where people get to learn stuff from the pro's. IIRC the problem of Joey is that no-one is suitable to take over his job!
16:26 < bubulle> fjp: yep, that's about the same idea
16:27 < bubulle> JW: fjp is suitable to this..:-)
16:27 < joeyh> bubulle: you mean, who owns which udeb?
16:27 < Kamion> (which Joey do you mean?)
16:27 < bouz> is it possible to reduce debian-boot load? The number of messages is frightening if you have few spare time.
16:27 < pere> JW: well, I guess it depends on who writes the requirement list.  is he writing it himself?
16:27 < joeyh> ok, that's a good point, perhaps we should split off the commit and bug messages
16:27 < joeyh> been talked about before
16:27 < bubulle> yep, I agree
16:27 < bouz> in particular there is no reason to receive BTS reports
16:27 < ths> joeyh: Seconded.
16:27 < jbailey> I might start reading debian-boot again then. =)
16:27 < pere> joeyh: yes, please move those away.
16:28 < Kamion> yeah, I think I agree - talk to listmaster@ and change all the maintainer lines ...
16:28 < joeyh> so, make a debian-d-i?
16:28 < vorlon> doesn't the wiki have a list somewhere of what areas people are taking credit for?  ping them all and hold them responsible unless they indicate otherwise. :)
16:28 < pere> joeyh: I believe we should keep debian-boot as the main list.
16:28 < fjp> We will still need people dealing with installation reports though.
16:28 < pere> vorlon: I believe the uploaders are the list of credit-takers for udebs.
16:29 < bubulle> so, let's try a short summary...
16:29 < vorlon> pere: udebs are easy; it's harder to figure out who's responsible for broader areas of functionality
16:29  * joeyh would like to see more people taking ownership of specific udebs
16:29 < bubulle> -need to looks over udebs, check the "owners" and see if all are "alive"
16:29  * JW wants to do more than he can. Who trains him :P?
16:29 < bubulle> -nominate one official "responsible" for a given udeb
16:30 < CIA-1> debian-installer: cjwatson * r28505 installer/doc/TODO: base-installer test suite more or less done
16:30 < fjp> JW: You train yourself and ask for help anytime you need it
16:30 < joeyh> Kamion: can we get the bts to cc uploaders somehow BTW?
16:30 < bubulle> -move bug reports and all administrivia messages to another mailing list
16:30 < fjp> joeyh: Uploaders can subscribe to BTS mails
16:30 < Kamion> joeyh: if Uploaders went into the Maintainers file that katie maintains, it'd happen automatically; dunno if that's the right approach
16:30 < bubulle> -publicize the debconf talk..:-)
16:30 < JW> I know. fjp; you have already helped me a lot. Perhaps the road to get an active Debian developper should be made more clear
16:30 < joeyh> yes, but that is a pain
16:31 < JW> and devided into small parts
16:31 < ths> bubulle: bugs and commits to two lists.
16:31 < joeyh> (the subscription)
16:31  * pere suggest we structure the uploaders list in udebs to list the udeb main responsible/developer first, and the others after that.
16:31 < Kamion> joeyh: ownership> mm, I'm ambivalent
16:31 < bubulle> OK, who volunteers to create the list for bugs?
16:32 < Kamion> joeyh: people drift in and out a lot, I'd hate to see us getting maintainer-locked
16:32 < pere> should we create it on alioth?
16:32 < bubulle> pere: that's the easiest way...unless the listmasters give us a push
16:32 < joeyh> Kamion: think more of joshk and netcfg (a while ago), or pere and discover
16:32 < pere> Kamion: I do not believe we are very volunable there, as everything is in a common repository, and we have lots of uploaders.
16:32 < bubulle> joeyh: or bubulle and localechooser..:-)
16:33 < Kamion> joeyh: ok, strong responsibility and knowledge is good, certainly
16:33 < pere> Kamion: but it is nice to have some coordination point for all packages, to make sure all developers work together in an udeb.
16:33 < bubulle> hmmm; still no volunteer for the bug list creation..:-)
16:33 < Kamion> pere: right, all I want to make sure is that it's still relatively easy to make changes across large chunks of d-i when that proves to be necessary
16:33 < fjp> Alastair and kbd-chooser...
16:34 < Kamion> fjp: ... and nowadays nobody really knows what kbd-chooser's about
16:34 < bubulle> About Alastair and kbd-chooser: http://wiki.debian.net/?EtchConsole2KbdTransition
16:34 < pere> Kamion: yes, we want to keep that, but also document the "head developer" in some way.
16:34 < fjp> bubulle: Yes, was very happy to see that
16:34 < pere> bubulle: only the d-i alioth admins can do that, right?
16:34 < bubulle> he mentioned wanting to keep involved with d-i devel, probably more than now
16:34 < fjp> kbd-chooser should be lots easier when 2.4 is dropped
16:34 < bubulle> OK, I'll request a list creation for bugs
16:34 < joeyh> one point re pulling people in is that it's much easier to learn how an existing udeb works, and maintain it, than it is to learn how to do full d-i development
16:35 < joeyh> for example, it's easy to work on os-prober, you don't need to make initrds and stuff.
16:35 < pere> and adding discover entries for new hw is dead easy.
16:35 < bubulle> how can we procees so that all bug reports go to this list. Need to re-upload packages or is there a smoother way?
16:35 < Kamion> bubulle: once it's set up I can do a mass override until everything gets reuploaded
16:35 < trave11er> pere: btw, are you planning to stick with discover1?
16:36 < bubulle> OK, so Kamion will handle the redirection
16:36 < trave11er> pere: or are there any plans to switch to discover(2)
16:36 < pere> trave11er: no, I want to move to discover2, but I need to bend it out of the dead fingers of progeny first.
16:36 < ths> fjp: 2.4 won't get dropped that soon, but hopefully before etch.
16:36 < trave11er> pere: ah, ok
16:36 < bubulle> Who builmds a list of udebs responsible persons?
16:36 < Kamion> hotplug seems more appealing nowadays ...
16:36 < fjp> bubulle: me
16:36 < Kamion> I realise there's controversy on this though
16:36 < pere> Kamion: hotplug only do part of the job of discover v2.
16:36 < bubulle> fjp: fine
16:37 < jbailey> Kamion: The initramfs detection stuff that I'm doing walks the 'modalias' bits in /sys.  If we go 2.6, there isn't much need for anything beyond 8 lines or so of shell script.
16:37 < bubulle> I suggest we keep this list somewhere in the SVN, just as I intend to do with the translators list
16:37 < Kamion> pere: in combination with pciutils/usbutils for getting device names, it's sufficient for the installer
16:37 < jbailey> (As far as what hotplug provides,)
16:37 < bubulle> joeyh: where do the commit messages go?
16:37 < pere> Kamion: well, I have bigger plans. :)
16:37 < joeyh> commit messages can easily be directed anywhere.
16:38 < Kamion> they're already a separate list aren't they?
16:38 < pere> Kamion: install sane if you see a scanner, install thinkpad packages if you see a thinkpad, etc.
16:38 < bubulle> but do they go in a list now?
16:38 < fjp> pere: Write a mail to -boot with an overview? Bet lot of ppl will be interested.
16:38 < joeyh> oh, are they?
16:38 < makx> ths: as soon as possible the better. :)
16:38 < Kamion> they're certainly not -boot
16:38 < joeyh> debian-installer_cvs@packages.qa.debian.org
16:38 < joeyh> heh
16:38 < pere> fjp: I'll try to find time, but as always, I am quite constrained for time. :/
16:38 < joeyh> we could probably stand to gate that to a better list
16:39 < bubulle> joeyh: yep. So I request for two lists?
16:39 < joeyh> more people reading commit messages would be good
16:39 < bubulle> d-i-bugs and d-i-commits @lists.alioth.d.o?
16:39 < bubulle> I'll subscribe to both undoubtfully
16:39 < bubulle> Well, seems we're over with thrid topic.
16:39  * pere will limit himself to the -commits list. :)
16:39 < jbailey> Is there any way to do a pts-like system where you can subscribe to the commit messages for bits that you care about?
16:40 < bubulle> ah no.joeyh: do we redirect installation-reports in the -bugs list too?
16:40 < Kamion> we could send stuff to <package>_cvs@packages.qa.d.o as well easily enough
16:40 < joeyh> only with mail filtering, and it's hard since commits can touch whole tree
16:40 < jbailey> Yup, makes sense.
16:40  * fjp thinks installation reports should be read by all
16:40 < joeyh> hmm, not sure how easy, it is doable though
16:40  * otavio is here. Sorry by the late
16:41  * bubulle would prefer keeping installation-reports to -boot so that more than a few people read them
16:41 < joeyh> more than zero..
16:41 < bubulle> hey, I do read them..:-)
16:41  * pere do not read installation reports before they are assigned to his packages.
16:41 < pere> even if they are posted on -boot.
16:41 < bubulle> pere: but we're actually lacking people to process them
16:42 < trave11er> it would help if installation report would be tagged at least with the arch
16:42 < bubulle> which requires a goo dknowledge of all d-i
16:42 < pere> bubulle: sure, but sending them to people not reading them are not helping in that regard.
16:42 < bubulle> trave11er: we can pseudo-tag them (or are there official tags for arches?)
16:42 < fjp> Volunteer needed to make new installation report template and possibly bynamic installation report web form...
16:42 < pere> can we get d-i to pre-fill in some info in the report template?
16:43 < fjp> eh, dynamic
16:43 < Kamion> bubulle: no, subject-tagging is in use
16:43 < joeyh> this is done, there's reportbug integration
16:43 < trave11er> bubulle: no, i think it would be good to modify the template asking submitters to put arch into the topic
16:43 < joeyh> assuming your install succeeds..
16:43 < trave11er> err, subject
16:43 < Kamion> trave11er: doesn't need to ask, just do it
16:43 < pere> joeyh: ah, great.
16:43 < vorlon> bubulle: not necessarily; it just requires enough knowledge to be able to kick the report off in the direction of someone who's awake, and can redirect it further if appropriate. ):
16:43 < vorlon> :)
16:44 < trave11er> Kamion: ah, you mean pregenerated template?
16:44 < bubulle> vorlon: this needs the one processing the report to actually *know* about who to redirect..:-)
16:44 < Kamion> trave11er: yes
16:44 < otavio> joeyh: maybe we could have one small tool installed inside of d-i to help us to write the installation report if it fail too
16:44 < otavio> joeyh: if we have  internet there, it can be send likewise
16:44 < trave11er> Kamion: i don't really know how many people are using those, i had the one on the web in mind
16:44 < vorlon> bubulle: nah; if all the udebs are well cared for, getting it wrong the first time doesn't matter too much
16:45 < bubulle> well, OK, I was about to conclude this topic as it derives a lot...so lets' conclude it....
16:45 < joeyh> well, with the web server we have, all the stuff needed to generate one can be exported to another host
16:45 < vorlon> because the report will just be passed along to whoever should have it
16:45 < pere> otavio: right, some exception handler... "Everything crashed, please press enter to submit a bug report"...
16:45 < bubulle> Next topic:
16:45 < bubulle> how to avoid breaking d-i too badly while doing unstable development; ie, coordinating changes
16:45 < otavio> pere: yes.
16:45 < bubulle> joeyh?
16:45 < bubulle> and fjp, of course..:-)
16:46 < joeyh> Totals: 66 tests (58 failed, 0 old)
16:46 < otavio> Using experimental?
16:46  * joeyh notes that all the successes are old CD images that are not being updated
16:46 < pere> automatic tests, and publising the results on the web?
16:46 < bubulle> joeyh: do you have ideas about what broke d-i most often?
16:46 < joeyh> pere: http://people.debian.org/~joeyh/d-i/test-logs.html
16:47 < joeyh> well, we have three classes of problems 1) debs change and break d-i
16:47 < Kamion> I find those logs too hard to use unfortunately
16:47 < joeyh> we can't do much about this except yell
16:47 < fjp> joeyh: Well, with broken debootstrap that's not that strange...
16:47 < joeyh> 2) non-svn udebs change and break d-i
16:47 < joeyh> 3) d-i breaks d-i
16:48 < bubulle> joeyh: the log files give  me Access Denied errors. Is it me?
16:48 < joeyh> logs seem ok here
16:49 < Kamion> the last full CDs on cdimage seem to date from 20050608
16:49 < bubulle> joeyh: while listing all "responsible" people for udebs, we should probably list people responsible for non d-i stuff (Alastair, aj, me for shadow...)
16:49 < p2-mate> zinosat: I think it's wise to keep as much options open as possible
16:49 < fjp> bubulle: Will do.
16:50 < bubulle> fjp: we should probably check they still follow closely d-i devel (most do, but..)
16:50 < pere> should a broken d-i be addressed imediately, all new development blocked until it is fixed?  If d-i tests are broken, we could just forbid new commits not fixing the problem?
16:50 < Kamion> ugh
16:50 < otavio> pere: this will include very long delays for development
16:50 < fjp> Don't think so, except maybe when working towards a release.
16:51 < p2-mate> zinosat: but an advantage of GTK is indeed that it's widely used and there are already a number of smaller sized programs running on it in the GPE project
16:51 < otavio> pere: i think use experimental could make this easier
16:51 < pere> perhaps, or teach people to test their stuff better before commiting.
16:51 < Kamion> there are too many bits of d-i for that to make sense IMHO
16:51 < bubulle> p2-mate: off-topic..:-)
16:51 < otavio> pere: but the problem is experimental doesn't have buildds for all arches
16:51 < joeyh> I'm more worried about broken d-i blocking development on its own.
16:51 < Kamion> e.g. if you tell anton he can't commit bits of partman, he'll just go offline for another month ...
16:51 < p2-mate> bubulle: no :)
16:52 < pere> well, the question is who gets to clean up the mess, and who get to keep the pieces when d-i breaks.
16:52 < joeyh> I think it's more important to coodinate these changes, try not to let the broken stuff stack up
16:52 < bubulle> pere: testing stuff is not always that easy when they're not in the netboot image
16:52 < pere> bubulle: yes, testing the installer is hard.
16:52 < bubulle> joeyh: yep...request at least some annoucements before beginning to work on break^W improving udebs
16:52 < joeyh> it's really bad when d-i is broken in multiple ways, then it becomes just a chore to fix
16:52 < joeyh> if it's broken in one way, there's a strong incentive to fix that one thing
16:53 < pere> should we at least annouce the broken d-i on -boot when it fails?  I didn't know the test results from joeyh, neither that it was broken all over.
16:53 < fjp> Major migrations should be announced and coordinated anyway.
16:53 < otavio> joeyh: maybe send the failed logs to -boot?
16:53 < joeyh> otavio: as kamion noted, they are really hard to read
16:53 < otavio> joeyh: this could be good since we all will know what is broken and theen help to fix
16:54 < Kamion> if the logs included /var/log/*, I'd look at them; as it is I just can't, I've tried and can't make head nor tail of them
16:54 < otavio> joeyh: and we can't improve it?
16:54 < bubulle> otavio: and ATM this would sound like spam, I'm afraid
16:54 < pere> at least the d-i syslog and base-config.log
16:54 < joeyh> otavio: can, but it requires messy and hard expect scripting
16:54 < ths> joeyh: But a "n of m failed, +-x" would be ok as mail.
16:54  * pere would rather have an url posted to -boot
16:55 < joeyh> also, I sometimes have hardware failures, etc, it's more of an early warning system for breakage than anything else
16:55 < otavio> joeyh: or then, send a daily message with small the failed tests  with links for them
16:55 < bubulle> joeyh: do *you* actually read these logs?
16:55 < Kamion> I wouldn't mind a daily lab report ...
16:55 < joeyh> bubulle: when something breaks, yes.
16:56 < pere> can we get all d-i message out of /var/log/messages and into /var/log/syslog, to make sure we only need to look in one file?
16:56 < bubulle> joeyh: so just bounce them to -boot when you feel it's appropriate (ie not twoce the same failure report)?
16:56 < joeyh> I can mail -boot when I know something is broken (so can others too)
16:56 < bubulle> or just automate them to a list...as long as someone other than joeyh reads them
16:56 < joeyh> or use the topic here.
16:57 < bubulle> hey, the topic seems a pretty good idea anyway
16:57 < bubulle> and the -commits list I would say
16:58 < fjp> Let's move on
16:58 < bubulle> OK...mothing more comes and people are falling asleep so next topic? :-)
16:58 < bubulle> throw out a few general development plans without being too specific (keep this for further, more specialized, meetings)
16:58 < joeyh> back to coordinating changes, here are some possible things I know of: 2.6.11, udev, busybox 1.0, hotplug, 2.6 as default on i386, alastair's stuff
16:59 < joeyh> I think we should try to only make one of these changes at a time and make sure d-i works before doing the next one.
16:59 < bubulle> so keep an alive list of these "big changes"...
16:59 < pere> moving timezone and root password question to first stage would also be nice.
16:59 < fjp> 2.6.11 means non-free udeb support?
17:00 < bubulle> OK, so general development plans:
17:00 < bubulle> first subtopics proposal;
17:00 < Kamion> I'm not sure splitting up udev and hotplug *necessarily* makes sense, but the rest yes
17:00 < pere> we should also get a standardize way to avoid module loading across both hotplug and discover 1/2.
17:00 < joeyh> the "make sure d-i works" bit is where the lab report is useful, if it's mostly passes.
17:00 < bubulle> keep supporting 2.4 kernel for etch?
17:00 < bubulle> so...should we? :-)
17:00 < pere> I believe we should.
17:00 < JW> What about making multiple d-i branches? I will be satisfied with every non-SATA pentium II version that fits a floppy. Added to that you can try to make some general guidelines and let others (sf.net ppl?) make all kinds of d-i?
17:00 < fjp> Which archs don't have 2.6 yet?
17:00 < trave11er> pere: why?
17:01 < joeyh> I belive we should support 2.4 until the kernel team stops supporting it.
17:01 < noshadow> Will 2.6 ever become stable?
17:01 < pere> make it easier to install sarge with the etch installer.
17:01 < bubulle> JW: not enough manpower for multiple branches and handling the releases...:-)
17:01 < Kamion> JW: we already have lots of d-i builds
17:01 < ths> fjp: i386, for some machines. :-)
17:01 < joeyh> mising 2.6: arm, mips, mipsel, m68k (partial), s390
17:02 < joeyh> oh and my laptop :-P
17:02 < Kamion> JW: major code forks between them are too hard to maintain, but there's no reason not to support lots of different installation methods, kernels, etc. in the one code base
17:02 < JW> okay. But why do I not see a list of choices for stable versions anywhere? This discussion is about 'being modern'...
17:02 < bubulle> this seemspretty of-topic ATM, I'm afraid
17:02 < Kamion> http://www.debian.org/devel/debian-installer/ports-status
17:02 < vorlon> aw, c'mon, you mean we can't decide to drop support for 2.4 and put the pressure on the arch porters to update if they want to ship with etch? :P
17:03 < bubulle> why not announce that in betaN we will stop supporting 2.4?
17:03 < joeyh> hmm, and um, I think alpha and a few other arches may have 2.6 udebs but not use them, not sure
17:03 < vorlon> joeyh: correct
17:03  * pere worked hard to get d-i to support installing woody, and would really love it if d-i in etch was able to install sarge for a long time.
17:03 < joeyh> is supporting 2.4 really so much added work for us?
17:03 < vorlon> fixable, though I have an open bug report to nobse about the SCSI card in my alpha. :)
17:03 < joeyh> most of the work seems to be on the kernel team side
17:04 < jvw> vorlon: but with s/2.2/2.4/, that *is* possible, right?
17:04 < vorlon> joeyh: well, 2.6.13 won't support devfs, and 2.4 sure doesn't support udev?
17:04 < ths> vorlon: OT, but which Model?
17:04 < fjp> joeyh: kbd-chooser could be a lot simpler without 2.4
17:04 < otavio> we can't drop discover when we start to use hotplug? at last on d-i?
17:04 < bubulle> joeyh: you're the best advice for this, imho..:-)
17:04 < joeyh> vorlon: sure, but iirc the d-i udev emulates devfs anyway, so..
17:05 < Kamion> vorlon: it's easy to support both devfs and udev in the same tree
17:05 < pere> do hotplug support listing prefered module for a given hw?  didn't last time I checked.
17:05 < vorlon> ths: 1077:1020 (rev 01)
17:05 < joeyh> otoh, I think we should drop 2.4 for specific arches if they're ready. Like was done for hppa
17:05 < bubulle> so, as a summary, we do no seem really ready to drop 2.4 support, both technically and "psychologically", right?
17:05 < Kamion> no, you do lose some configurability when using hotplug, because it just loads the module rather than returning a list
17:05 < jbailey> svenl metnioned before wanting to drop 2.4 for ppc*
17:06 < vorlon> svenl mentions wanting to drop 2.4 for ppc in every other breath
17:06 < Kamion> but it seems a valid thing to at least support nevertheless, even if not by default
17:06 < bubulle> hmmmmm: consensus going to "drop 2.4 support for arches whoc already have a working 2.6 support"?
17:06 < makx> yes 2.6 needs to be default for next release
17:06 < joeyh> bubulle: perhaps too strong; i386 does and I'm not suggesting dropping 2.4 from there
17:06 < ths> vorlon: That's a qla1020? I'm hacking on it currently for ip27. I might bother you to test the patch. :-)
17:07 < otavio> makx: but we have some machines just don't work with 2.6 yet. At last with 2.6.8 and in i386
17:07 < joeyh> makx: agreed.
17:07 < vorlon> I guess there's no reason internal to d-i to warrant dropping 2.4 at this point; I would still like to see more pressure to get rid of 2.4, so that etch might stand a snowball's chance of releasing with a single kernel.
17:07 < joeyh> otavio: but probably more the inverse.
17:07 < pere> bubulle: if we want to keep supporting sarge installs with the etch installer, we need to support 2.4 kernels where it was the default in sarge.
17:07 < bubulle> drop 2.4 support for arches whoc already have a working 2.6 support and where 2.4 is no more supported by the kernel team"? :-)
17:07 < joeyh> ie, all sata.
17:07 < otavio> joeyh: agreed.
17:07 < joeyh> bubulle: or where 2.4 support is useless, yes.
17:08 < ths> bubulle: Kernel version depends also on _sub_arches.
17:08 < pere> bubulle: nop. :)
17:08 < vorlon> bubulle: well, that's a no brainer, isn't it? :)
17:08  * bubulle notices that joeyh and pere seem to disagree here..:-)
17:08 < Kamion> if the kernel team desupport kernels on us, we don't really have an option :-)
17:08 < Kamion> have to switch to something else ...
17:08 < pere> we should of course try to get all archs to support 2.6, but that does not mean we should remove 2.4 support, or not try to write code handling both 2.4 and 2.6.
17:09 < Kamion> pere: particularly agreed on the latter - it just produces more portable code if people are keeping that in mind
17:09 < otavio> pere: we'll continue to support 2.4 untill all arches move to 2.6
17:09 < Kamion> pere: especially if/once we start trying to switch 2.6 to non-devfs paths ...
17:09 < pere> 2.8 will probably drop udev, so we need to start from scratch then. :)
17:09 < fjp> pere That's a good point. To install sarge with the Etch installer you would need 2.4 + 2.6.8 + 2.6.1[12]...
17:10  * bubulle is getting headaches here..:-)
17:10 < ths> I think "Don't delibarately break 2.4" is the best policy for now.
17:10 < otavio> pere: what hell 2.8 will use to replace udev?
17:10 < Kamion> otavio: nobody anticipated udev in 2.4 days
17:10 < bubulle> ths: I think that you made the best summary we can do, yes
17:10 < joeyh> probably something from opensolaris ...
17:10 < joeyh> :-P
17:10 < pere> otavio: who knows.   backwards compatibility is not very important for the kernel developers, it seem.
17:10 < otavio> ehehe
17:10 < otavio> joeyh: heheh
17:10 < bubulle> So, as Thiemo made a quite good conclusion, let's move
17:10 < noshadow> octavio: will there ever be a 2.8?
17:11 < bubulle> next subtopic on general plan:
17:11 < bubulle> 2.6 installation floppies
17:11 < otavio> noshadow: I hope. So 2.6 will start to work ;-)
17:11 < joeyh> heh, how did that get in there? If someone makes it work, we get it.
17:11 < bubulle> joeyh: you had size problems in mind, right?
17:11 < pere> bubulle:  are we done with all the future plans for d-i, or just the kernel issue?
17:11 < joeyh> I don't think it will be me getting it to work, I can tell you that :-)
17:11 < joeyh> yes, it doesn't fit
17:11 < fjp> So volunteers who have the skills needed?
17:11 < bubulle> pere: there are a few other kernel stuff, that's all.
17:12 < vorlon> ths: so yeah, send me patches to test -- it doesn't block me from doing 2.6 d-i work on alpha, but it'd be nice to be able to upgrade that system. :)
17:12 < otavio> to me, makes sense improve hotplug and then remove discover from install time.
17:12  * joeyh would suggest looking at uclibc and/or klibc
17:12 < jbailey> fjp: I think I still have a machine with a floppy drive.... =)
17:12 < bubulle> pere: all other more specific details should rather go post-meeting or, better, in another not too far, meeting
17:12 < joeyh> ... and using qemu :-)
17:12 < pere> bubulle: right.  I lost track of the topic position we were at.
17:12 < fjp> jbailey: me too (3 in fact), but I don't have the skill...
17:12 < fjp> jbailey: Can test though.
17:13 < jbailey> fjp: I suspect I have the sk1llz.  Sure, why not? =)
17:13 < fjp> Great
17:13 < bubulle> but is 2.6 install floppies support worth the effort?
17:13 < Kamion> joeyh: is it still that the actual kernel image doesn't fit, or is it just kernel+initrd?
17:13 < makx> well for alpha i would like them.
17:13 < joeyh> well, it is if we drop 2.4.
17:13 < joeyh> Kamion: kernel + initrd
17:13 < joeyh> Kamion: there was a subthread on -devel
17:13  * pere do not have a machine with floppies, and more and more servers arrive without floppies too.
17:14 < fjp> bubulle: If we don't we are stuck with 2.4 for systems that can't boot from CD or net
17:14 < makx> seen on d-alpha people suggesting woody and then upgrade because of the floppies..
17:14 < jbailey> If it's just kernel + initrd, I beleive I know how to solve in reasonably for 2.6
17:14 < Kamion> bubulle: even in Ubuntu, which is not exactly a distro favoured by people with ancient hardware, we get pretty regular requests for floppy installs
17:14 < vorlon> makx: for *alpha* you would like 2.6 floppies?
17:14 < bubulle> Kamion, fjp: OK...just wanted to be sure..:)
17:14 < pere> I guess we need floppies if we want to take over the developing countries.
17:14 < jbailey> vorlon: My alpha only has a floppy drive. =)
17:14 < vorlon> I couldn't even be bothered to make them fit for 2.4. :P
17:14 < vorlon> jbailey: how about a network card? :)
17:15 < jbailey> vorlon: Phhh..
17:15 < vorlon> netboot support in the firmware... screw floppies
17:15 < bubulle> pere: are you so sure tha developing countries will still only have machines booting with floppies when we'll release etch?
17:15 < p2-mate> jbailey: it runs from ramdisk ?
17:15 < makx> vorlon: my machines didn't like tftp-ha
17:15 < jbailey> p2-mate: right.  And initramfs is completely writable.
17:15 < joeyh> jbailey: bear in mind that the boot floppy is also currently used for booting usb sticks if the bios can't/
17:15 < pere> bubulle: yes, quite.
17:15 < p2-mate> jbailey: you have a few GB of battery backed RAM then ?
17:16 < noshadow> babulle: floppy drives work endlessly, cdrom drives are often trashed or cannot read burned devices and all such things...
17:16 < bubulle> OK, /me is not convinced, but anyway..:-). I think that floppy support is more wanted for uncommon arches
17:16 < jbailey> joeyh: 'kay.  I have usb sticks now, too.
17:16 < Kamion> some people use smart boot manager to cope when only floppy boot is available
17:16 < vorlon> makx: I've been using the tftpd package rather than tftp-ha.  There is some per-arch fiddliness in that regard; joeyh is the expert. :)
17:16 < Kamion> but that's an i386ism I think
17:16 < p2-mate> bubulle: most uncommon archs don't have floppy drives :)
17:16 < JW> What exactly are the reasons to want 2.6 floppies? You can easily install a 2.6 system from a 2.4 floppy! If D-I needs it you can also get it to work with other systems or a D-I specific kernel...
17:17 < bubulle> So, let's conclude that small subtopic : we need to work on 2.6 floppies..:-). At least this is what I understand from the mess above..:-)
17:17 < Kamion> JW: installing with a radically different kernel tends to result in hardware detection problems, so I don't recommend it
17:17 < Kamion> JW: you might've been lucky
17:17 < otavio> Kamion: maybe try to have a smart boot manager for other arches?
17:17 < pere> JW: making sure the stuff that worked in d-i keep working in the installed system is normally easier if both boots the same kernel.
17:17 < JW> I think rescue support on installation floppies is a bigger issue...
17:17 < joeyh> it's already done.
17:17 < JW> thanks for the answer pere.
17:17 < bubulle> Next subtopic:
17:17 < makx> JW: 2.4 will be dropped in middle term
17:17 < bubulle> still on kernel issues
17:17 < JW> oh no!
17:18 < bubulle> 2.6.11 installer
17:18 < bubulle> with one comment added:
17:18 < bubulle> (this could have the danger that backporting changes to Sarge for the 2.6.8 kernel could become more tricky, but advantage is we get a solution for all those SATA problems)
17:18 < fjp> bubulle: Already covered?
17:18 < pere> what is special about 2.6.11, compared to 2.6.8?
17:18 < bubulle> yep, mostly already covered by discussions about the sarge installer 
17:18 < Kamion> what kind of backport concerns are these?
17:18 < pere> (except the broken audio support on my laptop. :)
17:18 < joeyh> pere: sata and other hw works better
17:18 < bubulle> Kamion: dunno, I don't remember who proposed this..:-)
17:19 < jbailey> I think 2.6.11 is when the kernel grew modalias support, convenient for hw detection.
17:19 < JW> how small can it be build? I know freedos.org fits a 1.6Meg kernel on a floppy...
17:19 < bubulle> Kamion: ah, this was joeyh
17:19 < pere> jbailey: is that the kernel folks workaround for switching module names all the time?
17:19 < Kamion> JW: see threads on mailing lists ...
17:19 < joeyh> well, my question re 2.6.11 is, do we want to switch to it now, with missing tg3 and other drivers, or wait for those to get into non-free?
17:19 < JW> okay Kamion... sorry. must have missed some :-P
17:19 < fjp> Kamion: Well, if you develop in trunk with only 2.6.11, you could run into unexpected things when you port changes to the Sarge branch for use with 2.6.8 kernels
17:20 < Kamion> joeyh: I'd rather switch to it now and hammer out other issues
17:20 < vorlon> Kamion++
17:20 < Kamion> fjp: yeah, but I can't think of many things that that would actually affect
17:20 < bubulle> same for me (pure feeling but you know me)
17:20 < trave11er> joeyh: the demand for 2.6.11 is pretty big right now
17:20 < jbailey> pere: It seems to be. =)  /boot/modules.alias includes the list of the modaliases that any given driver supports, /sys populates modalias.  It seems to be a PCI or USB unique ID of some sort, I haven't disected the magic number.
17:20 < pere> joeyh: if the kernel support less hw than the earlier versions, I believe we should stay with the kernel supporting mosthw.
17:20 < otavio> and if we support the new and the stable kernel on the images?
17:20 < fjp> Will be easier to work on non-free support if we already have a 2.6.11 installer
17:20 < joeyh> pere: I think it's hard to get a number for that.
17:20 < Kamion> pere: it appears to support *different* hardware
17:20 < bubulle> imho, having 2.6.11 would necessarily boost the work on non-free drivers support
17:21 < joeyh> probably one supports someone's hard drive but not ethernet, and the other ethernet but not hard drive
17:21 < vorlon> pere: and at the same time, the kernel team is working exclusively on 2.6.11/2.6.12, 2.6.11 is already in testing, ...
17:21 < fjp> Maybe add a warning dialog that some hardware is not supported?
17:21 < pere> oh, great. sidegrades, not up/downgrades.
17:21 < otavio> bubulle: but this will need to be done anyway since we won't deliver  non-free modules anymore
17:21 < vorlon> I expect that kernel-latest-* are going to point to 2.6.1* soon
17:21 < Kamion> fjp: could certainly warn in release announcements
17:21 < makx> well we also need to rename those because of hurd and *bsd
17:22 < bubulle> so, like it or not, we have to follow the kernel team here
17:22 < makx> latest name seems to be linux-image for the unified package
17:22  * pere do not like it, but know bubulle is right on that one. :(
17:22 < joeyh> anyone here who knows when the kernel team plans to upload the non-free modules?
17:22 < ths> vorlon: 2.6.12 is it. .11 is wasted time soon.
17:22 < makx> uups sorry s/linux-image/linux-kernel/
17:22 < trave11er> makx: linux-kernel is proposed name for the source package, everything else will just get s/kernel-/linux-/
17:22 < vorlon> ths: yeah, too bad these decisions are made faster than our architectures ever sync up on a single kernel version :P
17:23 < pere> but we need to come up with a way to make it possible to fetch the firmware/non-free modules dynamically during installation.
17:23 < joeyh> well, I've done some work on it
17:23 < ths> vorlon: That was my primary concern with it.
17:23 < joeyh> I can pretty easily finish support for catting non-free udebs to the end of initrds
17:23 < joeyh> not sure what to do for CDs
17:23 < bubulle> everyone agrees that if we go for 2.6.1* it will be for 2.6.12 or more?
17:23 < pere> is the list of affected modules short?  i'm aware of tg3.
17:24 < bubulle> pere: I am too. All my Dell servers use these
17:24 < joeyh> tg3, acenic, dgrs
17:24 < joeyh> afaik
17:24 < bubulle> pere: so count on me to be the whiner when we will break support for them..:-)
17:24 < joeyh> I see no reason to wait for 2.6.12. 2.6.11 is working in-tree, only needs to be turned on, afaik.
17:24 < fjp> bubulle: You know what to do when something you need is broken :-)
17:25 < joeyh> unless kernel team uploads 2.6.12 beforehand
17:25 < Kamion> the best kernel is always the next one
17:25 < pere> so we should support 2.6.8 and 2.6.11?
17:25 < Q_> If we're going to move to 2.6.11 or 12, does that mean we'll soon move to .13?
17:25 < vorlon> ths: maybe we should talk in a kernel-team context about having a minimum fixed period for developing on a particular kernel release (modulo security-fix releases), so that we can get into some sort of rhythm that allows for continuous releasability...
17:25 < bubulle> fjp: but there are issues I absolutely can't do anything about but while..:-)
17:25 < Kamion> I agree that there seems to be little point in waiting
17:25 < bubulle> whine
17:25 < joeyh> I imagine we'll keep right on tracking new 2.6's once we go to .11
17:25 < joeyh> unless devfs stops us.
17:25 < dannf_> tg3, qla2xxx, acenic & dgrs look like the most important non-free modules for installs
17:25 < fjp> joeyh: What about pere's question?
17:25 < joeyh> qla2xxx?
17:25 < bubulle> OK, general agreement to go to 2.6.11 ASAP. This seems to conclude that subtopic
17:26 < Kamion> really shouldn't ... just need to get Marco to start building udev-udeb, and figure out what to do with the debian-installer-startup script that he wants to ship in udev-udeb but I'd rather have in rootskel
17:26 < trave11er> joeyh: that's qlogic scsi drivers
17:26 < ths> vorlon: Well, I was mostly ignored by the people who do the work, with a bit of handwaving about the problem.
17:26 < pere> bubulle: as the only option, or one of several options?
17:26 < fjp> Do we want to support installing sarge (using 2.6.8) from Etch installer?
17:26 < joeyh> if we want to keep sarge installability, and I think we do, we need to keep supporting 2.6.8, I suppose.
17:26 < dannf_> & fibre channel
17:26  * bubulle agrees we should also keep support for sarge installs
17:26 < vorlon> ths: well, let me go grab my RM cudgel, so I have something heavy for when I'm waving my hands back. ;-)
17:26 < Kamion> we can keep the sarge package names in the base-installer test suite to make sure it keeps working
17:26 < Q_> Will we get new kernel images in sarge?
17:26 < joeyh> trave11er: is it in kernel-nonfree-modules-2.6.11-1-386?
17:26 < fjp> I agree.
17:27 < vorlon> Q_: yes, but not necessarily new upstream versions
17:27 < trave11er> joeyh: yes
17:27 < JW> I sure want sarge compatibility in newer D-I!!!
17:27 < joeyh> trave11er: don't suppose you know when it will hit incoming?
17:27 < trave11er> joeyh: the kernel-nonfree stuff?
17:27 < joeyh> even if it doesn't have all the removed stuff
17:27 < joeyh> yes
17:27 < bubulle> OK, last topic, folks...
17:27 < trave11er> joeyh: it's dilinger's turf
17:27 < dannf_> joeyh: dilinger was waiting on one more response from a copyright holder, last i heard
17:27 < bubulle> added last minute by fjp..:-)
17:28 < trave11er> joeyh: i'll ask
17:28 < ths> joeyh: Has still unresolved licensing issues.
17:28 < bubulle> switch back to release names in generated sources.list?
17:28 < JW> yes. good idea
17:28 < bubulle> frankly, this seems a bit too specific for today, but well...
17:28 < bubulle> fjp: develop?
17:28 < JW> It is the first thing I do on every system I install
17:28 < joeyh> massive number of both plusses and minuses
17:28 < Kamion> seems to be part of more general issue of being able to actually test the release before releasing it
17:29 < Kamion> (c.f. 3.1r0a)
17:29 < pere> yeah, or having more experience with releasing.
17:29 < vorlon> joeyh: what are the highlights of the minuses?
17:29 < fjp> joeyh: I'm unsure of the minuses
17:29 < joeyh> vorlon: people ending up stuck in oldstable w/o realizing it, for one
17:29 < bubulle> same for le about the minuses...and I do just like JW for my machines
17:29 < JW> Isn't one of Debian's policies to maintain great compatibility? We shouldn't make it the default to upgrade to newer (heavier) versions of Debian by means of just stating 'stable' in sources.list.
17:30 < noshadow> joeyh: Is that a bigger danger than people getting supprised by an uprepared update to the new stable?
17:30 < vorlon> right.. vs. having an unscheduled massive automatic upgrade from oldstable -> stable? :)
17:30 < joeyh> there's a base-config bug somewhere with a fairly complete discussion, although it misses the most recent plus to the change
17:30 < pere> JW: I do not believe it is one of debians policies, no
17:30 < bubulle> joeyh: well, on production machines, all massive upgrade between two stable releases has to be planned anyway
17:30 < fjp> Or people installing testing to get sarge and getting sucked into Etch unnoticed
17:30 < JW> pere: hmm... it should be :-P
17:31 < trave11er> ls
17:31 < joeyh> fjp: yes, that's the new plus.
17:31 < trave11er> oops
17:31 < bubulle> I actually see more plusses than minuses and I feel that this is shared..
17:32 < joeyh> we could address that one by putting release names in if the code name != stable
17:32 < fjp> joeyh: Good compromise
17:32 < pere> joeyh: yes, that would be the correct behaviour.
17:32 < Kamion> that would help, although we still have the QA issue
17:32 < vorlon> as long as it's agreed that using "stable" is correct for stable
17:32 < noshadow> joeyh: That still forces people to replace stable by the codename to be prepared when a new stable comes...
17:32 < Kamion> but perhaps we can think of other ways to help that
17:32 < fjp> Kamion: QA issue?
17:32 < pere> vorlon: ?
17:33 < bubulle> noshadow: /me hopesthat noone mentally sane does "apt-get -y dist-upgrade" on stable machines...
17:33 < joeyh> noshadow: I think that teaching people to not blindly answer "y" when apt-get suggests upgrading 5000 packages and removing 200, is a general good idea.
17:33 < vorlon> pere: the issue of automatic upgrades when a new stable release comes out
17:33 < Kamion> fjp: we couldn't test that 3.1r0 did the right thing without hacking a local mirror
17:33 < joeyh> and frankly, I have little syumpathy if they do.
17:33 < Kamion> fjp: hence why it broke
17:33 < jvw> bubulle: well, if you only expect the point releases...
17:33 < pere> vorlon: I believe joey proposed to put 'woody' or 'sarge' in there if release is stable, not 'stable.
17:33 < jvw> bubulle: which should be really minor updates
17:33 < vorlon> pere: he proposed just the opposite
17:33 < noshadow> babulle: no, but upgrade is enough and sometimes you are used to type y
17:34 < JW> you can make an installation immage for the Stable Debian and for Debian Sarge :-P
17:34 < Kamion> joeyh: lessons that people learn once every two years tend not to stick all that well, though
17:34 < noshadow> babulle: and when only security is affected, one may not even realize it is doing stupid things...
17:34 < pere> vorlon: oh.  then I disagre with joeyh.
17:34 < Kamion> (he says optimistically)
17:34 < otavio> pere: he proposed to use codenames if is different of stable (eg, etch, sid)
17:34 < CIA-1> debian-installer: bubulle * r28506 packages/po/eo.po: [l10n] [l10n-sync] Updated packages/po/* with general template.pot
17:34 < bubulle> hey, bubulle stop commiting during meetings..:-)
17:35 < bubulle> anyway, it seems the meeting is over. We went over all proposed topics
17:35 < pere> If I use stable, I expect it to keep working until I actively upgrade it.  if I use testing or unstable, I expect it to change in unexpected ways.
17:35 < JW> pere: yes, so did joeyh propose
17:35 < joeyh> stable upgrades, by definition, should keep working ...
17:35 < joeyh> anyway, I think this needs more discussion later.
17:36 < fjp> At debconf?
17:36 < pere> joeyh: upgrading woody->sarge isn't working.
17:36 < joeyh> um, if people have time, can we wrap up with some short term plans?
17:36 < noshadow> joeyh: I think every major upgrade should need human intervention. Principle of least suprise...
17:36 < pere> (at least not for all packages.)
17:36 < bubulle> So, this more generally concludes that d-i meeting
17:36 < JW> just a lost question: how to get into debconf?
17:36 < bubulle> joeyh: just lt me conclude..:-)
17:36  * pere got some time
17:36 < fjp> bubulle: Thanks for chairing
17:36 < dannf_> joeyh: is it useful to upload l-k-di's for 2.6.11?
17:36 < Kamion> I think most of my short-term plans are in installer/doc/TODO
17:36 < bubulle> Thanks to everyone around and for your patience with the bloody moderator
17:36 < JW> blah. My train leaves in 10 minutes... got to run!!!
17:36 < JW> se you later!!!
17:37 < makx> ok cu
17:37 < joeyh> something like a. get debootstrap fixed b. etch cds c. 2.6.11
17:37 < bubulle> I logged the whole stuff
17:37 < bubulle> and unless someones volunteers, I'm afraid I'll have to write the summary..:-)