Ubuntu Wiki

TZ UTC+1

05:01   mdz     ok, let's get started
05:01   mdz     cjwatson: Tim isn't here today, right?
05:02   cjwatson        no, holiday; that's noted on the agenda
05:02   mdz     agenda is at https://wiki.ubuntu.com/DevelTeamMeeting20070208
05:02   mdz     cjwatson: let's put that at the top in the future
05:02   mdz     and I'm here :-)
05:02   cjwatson        mdz: sure, I'll edit the template
05:03   mdz     are there any additions or deletions to/from the agenda?
05:03   Keybuk  gnargh!
05:03   Keybuk  COLIN, PLEASE OBEY WIKI LOCKS
05:04   cjwatson        huh? I see no lock errors
05:04   cjwatson        perhaps I missed it, if so sorry
05:05   Keybuk  np; you just did it twice in a row to me :p
05:05   BenC    FYI, ogra is listed twice on wiki, once with "NO REPORT..." and once with a report
05:05   fabbione        BenC: once for each of ogra's personalities
05:05   Keybuk  I suspect ogra added it himself
05:06   mdz     ok, taking the agenda as-is
05:06   Keybuk  ogra: you're most welcome to participate in the meeting, but please do get your report in by the end of Wednesday -- we pre-edit the agenda and send it out; if you add it yourself, people may not see it
05:06   ogra    yeah i did
05:06   mdz     "New Archive Team" has no name attached to it
05:06   ogra    Keybuk, yes. i'll be on time next week, really sorry for that
05:06   mdz     er, wrong agenda
05:06   Keybuk  mdz: errrr
05:06   mdz     asac: your agenda item?
05:06   mdz     (asac) Alexander wants to go over his firefox packaging changes with Ian.
05:07   cjwatson        that was one I added on asac's behalf to ensure that that got done soon
05:07   iwj     asac: Sure, how about right after this meeting ?
05:07   mdz     sounds like something the two of you could take care of out of band, rather than in this meeting
05:07   cjwatson        (since it was in his report)
05:07   cjwatson        it certainly doesn't need to happen in the meeting
05:07   mdz     ok
05:07   Keybuk  ACTION iwj and asac to talk about firefox packaging changes
05:07   asac    iwj: actually I am not here today :) ... I will upload it and we can go through it tomorrow?
05:07   iwj     asac: OK.
05:07   mdz     sounds good
05:07   mdz     the sooner the better
05:07   asac    fine ... actually I am quite optimistic that we get patches sorted out
05:08   iwj     asac: Sure but I'm away tomorrow ...
05:08   asac    there is only one major patch we might really get trouble getting upstream approval for
05:08   asac    the thai patch
05:08   iwj     Let's take these details offline.
05:08   asac    iwj: weekend?
05:08   mdz     asac: yes, that's come up with upstream already.  need to connect the person who wrote it with upstream to get it into shape
05:09   mdz     next agenda item: Will the following specs make release? (Scott James Remnant, Colin Watson)
05:09   asac    mdz: fine. Can you CC me, so I know the author?
05:09   mvo     asac: thep wrote it, hes around quite often in irc
05:09   Keybuk  right
05:09   Keybuk  iwj: your spec update didn't include any estimate of whether winmodem-support or automated-testing-deployment might make the release?
05:09   Keybuk  what's the status of those two specs?
05:09   iwj     automated-testing-deployment> Is largely decoupled from the release cycle.  So since it wasn't urgent for feature freeze it got put on hold at Keybuk's request.
05:09   mdz     asac: mvo should have his contact info; I don't have it to hand
05:10   asac    mdz: ok ... noted ... will ping mvo
05:10   Keybuk  *nods* the udev-* stuff was higher priority -- but if you started on that now, would you complete it before the release?
05:10   iwj     winmodem-support> It is now evident that it won't make the release.  I've been chasing after udev breakage the last day or two when I had hoped to be fixing up and promoting sl-modem-daemon.
05:10   mdz     iwj: even so, there's little potential to benefit from it for the release unless it's deployed soon
05:10   iwj     mdz: Indeed.
05:10   iwj     Although one benefit will be for security testing.
05:11   cjwatson        How long would winmodem-support take, out of curiosity?
05:11   tfheen  and we'll be gearing up, not down as we get closer to the release.
05:11   iwj     cjwatson: I spoke to mjg59 and I got the impression it was just a matter of putting together existing stuff in a slightly sane way.
05:11   iwj     I can get automated-testing running here out of cron with a week's work or so if I don't do anything much else that week.
05:11   mdz     I said the same thing about it in November.
05:12   iwj     mdz: Right, but I have the hardware now (since last week).
05:13   Keybuk  ok, otherwise your specs are now in good order; thanks especially for taking on some of the work from me
05:13   iwj     NP
05:13   Keybuk  udev-mdadm didn't take you as long as you feared?
05:13   Keybuk  (or is the spec status in LP wrong?)
05:14   mdz     if that's true, we will get more value out of automated testing than winmodem-support, since it should benefit a larger proportion of users
05:14   iwj     udev-mdadm was more straightforward than I feared but less easy than the spec said :-).
05:14   mdz     but winmodem-support is worth pushing in late if it's not too intrusive for users who don't have the hardware
05:14   iwj     Keybuk: LP> Oh, I probably forgot to update the status.
05:14   Keybuk  good.  the testing spec is the most important one to get done next, as that will be useful in the shortest time scale
05:14   fabbione        iwj: next week i am going to stress test the udev-* on the systems i have home that suck at bringing up disks at a normal speed
05:15   Keybuk  and as mdz just said, we should also get winmodem-support in, even past FF
05:15   tfheen  mdz: I would want it properly regression-tested so we don't end up loading modules which destabilise the system, since loads and loads of laptops have winmodem hardware.
05:15   iwj     mdz, Keybuk: Can I get you two to agree on priorities so know what I want to be working on ? :-)
05:15   mdz     tfheen: afaik, they're already loading the appropriate modules
05:15   Keybuk  iwj: I think we just did agree on priorities :p
05:15   iwj     fabbione: Right.  I think you'll find it's fine.
05:15   mdz     iwj: it sounds like we do
05:15   fabbione        iwj: i am sure it will be fine... i like to be the devil advocate ;)
05:15   tfheen  mdz: not my laptop at least.
05:15   iwj     OK, I'll do the winmodem support first since it's probably smaller.
05:16   Keybuk  *blink*
05:16   mdz     iwj: talk it over with Keybuk out of band
05:16   iwj     mdz: OK
05:16   mdz     moving on to mvo
05:16   Keybuk  mvo: dist-upgrader-fixes
05:16   mvo     dist-upgrader-fixes> -> Half is done, a backport of apt fixes is requested (DPkg::StopOnErrors patch, no changes to existing codepathes). Biggestet MISSING thing is runing the frontend and the backend in two different processes. this is prototyped, but python lacks a mechanism to pass file descriptors over sockets between processes. this is added in update-manager (fdsend module) now, so we can use this for the next release (then we will have https://blueprints.launchpad.net/ubuntu/+spec/dist-upgrader-arch-any too)
05:17   Keybuk  there wasn't anything in your report saying whether it'd miss FF but be ready for the Release, be ready for FF, or miss the Release
05:17   mvo     some bits are ready now
05:17   Keybuk  will the missing bits be ready before the release?  (ideally soon)?
05:17   mvo     the process seperation will miss release unless we backport the fdsend module to edgy
05:17   mdz     I don't think we should make major structural changes to the upgrader at this point
05:18   mvo     and for the better error handling I would like to add a patch to edgy apt
05:18   mvo     agreed
05:18   cjwatson        SRU stuff is later on the agenda
05:18   mdz     mvo: what's the potential benefit of the StopOnErrors backport?
05:18   mvo     mdz: apt will not stop if a dpkg --unpack/configure run fails
05:19   mvo     but keep going as long as possible
05:19   mvo     and report the broken packages
05:19   mvo     it won't change the behaviour by default
05:19   mvo     just when run under the upgrader
05:20   mdz     doesn't sound like a straightforward one to evaluate
05:20   mdz     let's discuss via email with the SRU team
05:20   mvo     fine with me
05:20   mdz     ACTION: mvo to discuss StopOnErrors backport with SRU team
05:20   pitti   still, if things break with the upgrader, that would be bad
05:20   mdz     tkamppeter: printerdriverautodownload?
05:20   cjwatson        that has made significant process since we last talked, according to Till's update
05:21   cjwatson        so I would like to know roughly how much longer it's expected to take, to see if it's worth an FF exception now
05:21   tkamppeter      I have made the first driver packages and put them up on OpenPrinting
05:22   tkamppeter      And I have updated the sites CGI scripts so that the packages are shown, added install instruction, and announced the new service.
05:23   tkamppeter      For making a source .deb which auto-downloads all available packages when building. I have some questions:
05:23   mdz     the spec calls for changes to PrinterDrake, which isn't shipping in this release
05:23   tkamppeter      Is it possible to convert a source RPM into a .deb source (.orig.gz, .diff.gz, dsc)?
05:24   pitti   mdz: these parts aren't crucial at all AFAICS, just nice to have (better integration)
05:24   tfheen  tkamppeter: you can't download anything off the net when you build a package.
05:24   pitti   tkamppeter: not universally; what do you need that for?
05:24   pitti   tfheen: the idea is something like 'debian/rules upstream-update'
05:25   cjwatson        tkamppeter: this should be a proper source package, not one converted from another format, IMO
05:25   mdz     this implementation sounds less and less like the summary of the spec
05:25   tkamppeter      The idea which was brought in for Ubuntu was making Ubuntu .deb packages from the available distribution-independent driver packages in an automated way.
05:25   pitti   tfheen: i. e. at some point you fetch the stuff from openprinting, then update the source package, and run the tests, etc.
05:25   tfheen  pitti: well, that's fine of course.
05:25   mdz     cjwatson,pitti,tkamppeter: how about the three of you review this out of band and come to a decision?
05:25   cjwatson        mdz: it's what's in the wiki page, though, more or less
05:25   pitti   mdz: fine for me
05:25   mdz     ok
05:25   cjwatson        the discussion evolved a fair bit since the LP spec summary was written
05:26   mdz     ACTION: cjwatson/pitti/tkamppeter to review printerdriverautodownload and come to a decision regarding its fate for feisty
05:26   mdz     Kubuntu Upgrader needs patches backported to kdelibs, kdebase and adept but also the feisty version of python-kde3 backported, which means backporting also python-qt3 and sip4-qt3, is that OK to go into edgy-updates after the usual SRU process? (Jonathan Riddell)
05:26   mdz     ouch
05:26   Riddell mostly just a warning
05:27   Riddell we need the fesity python-kde3 for the new embedded konsole
05:27   mdz     my gut feeling just based on the scope of the changes is that we should release this with feisty and not backport it to edgy
05:27   Riddell and that needs the feisty versions of python-qt3 and sip
05:27   Riddell mdz: that defeats the point of a dist-upgrader, which is very badly needed
05:28   mdz     Riddell: it doesn't; it just makes it one release later
05:28   Riddell there's only limited packages that use python-kde3 and -qt, it's possible to test them all for breakage
05:28   mdz     it doesn't meet the criteria for an SRU
05:29   mdz     well, not obviously anyway
05:30   mdz     it depends on just how poorly the upgrade experience is now, I suppose
05:30   mdz     but it's a very large change to weigh against the benefits
05:30   Riddell judging by dapper->edgy very poor
05:30   sfllaw  Is there some way to statically compile for just that app?
05:30   tfheen  we need to solve this problem for dapper->next LTS too, at some point.
05:30   sfllaw  Then we could limit the breakage.
05:30   pitti   sfllaw: urgh @ security updates then
05:31   tfheen  sfllaw: that would mean shipping a statically compiled python, I think?
05:31   cjwatson        statically compile> include copies of the relevant modules with the upgrader?
05:31   cjwatson        UGLY, but ...
05:31   mdz     Riddell: have you talked with mvo about it?
05:31   mvo     statically compile> we would need autobuilder support for that
05:31   mvo     well, not really, but it would be really good to have that
05:31   cjwatson        I'm still convinced that you already have it
05:32   mvo     we may have arch-any upload support, but I'm pretty sure we do not have auto-builder support
05:32   cjwatson        well, might need a bit of a source package restructuring, but I think the archive-side support is all thre
05:32   cjwatson        there
05:32   Riddell mdz: yes
05:32   mvo     its not a .dsc file afterall, just a tarball
05:32   cjwatson        a source package can spit out anything as long as it goes in a .changes file :)
05:32   cjwatson        right, the source package would need to be fixed
05:33   mvo     cjwatson: that would be a interessting option, can we talk offline about this?
05:33   cjwatson        sure
05:33   cjwatson        ACTION: cjwatson and mvo to discuss dist-upgrader autobuilding
05:33   mdz     sounds like another conversation for the SRU team
05:33   mdz     (the Kubuntu upgrader situation, that is)
05:34   Riddell == cjwatson and pitti?
05:34   mdz     ACTION: cjwatson/pitti/Riddell/mvo to discuss Kubuntu upgrade options for edgy->feisty
05:34   pitti   ack
05:34   mdz     A friend of mine just phoned me, he created a Qt GUI implementation for apport; do we want that in Feisty? It'd require us to copy over the apport bits of update-notifier to adept-notifier (shouldn't be hard, there's nothing GTK specific in it) (Martin Pitt)
05:34   pitti   I tested the current bzr head version (under Gnome, though)
05:34   pitti   it principally works
05:34   Riddell what are the apport bits of update-notifier?
05:34   cjwatson        I would love to make ubiquity more consistent between GNOME and KDE as regards crash reporting
05:35   mdz     I see no reason why we wouldn't want it
05:35   pitti   modulo some bugs in the Qt/Gnome frontend and qt itself
05:35   pitti   but it's mostly cosmetics
05:35   mdz     pitti: is it something you can hand off to Riddell for most of the integration work?
05:35   pitti   Riddell: calling apport-checkreports and displaying a tray icon or calling apport
05:35   pitti   mdz: I'm happy to work with him to get it going
05:35   pitti   the u-n bits for apport are entirely GTK-independent
05:35   pitti   well, almost, the tray icon needs different treatment, I guess
05:36   pitti   but the branch just arrived today, so it's quite on the edge of FF
05:36   pitti   how'bout me uploading apport-qt to the archive today for more widespread testing?
05:36   pitti   (universe for now)
05:36   mdz     it's worth having, but only if it doesn't require much wore work for you
05:37   pitti   Riddell: my principal question is to you, whether you actually want it
05:37   mdz     does it make the difference between having apport in Kubuntu or not?
05:37   Riddell pitti: sounds fun, my main worry remains how it interacts with the normal KDE crash handler and how annoyed upstream would get if we replaced it
05:37   pitti   mdz: Michael agreed to help with bug fixing in the qt port itself, so it's just the adept-notifier bits
05:37   pitti   Riddell: if kcrash intercepts sigsegvs, apport won't kick in
05:38   Riddell ok, that's an easy way around
05:38   pitti   Riddell: so it'd only be used for non-KDE programs, as long as you keep krash enabled
05:38   Riddell mdz: it would yes
05:38   pitti   and that depends on how happy upstream is with the krash reports they get
05:38   Riddell pitti: there's a couple people who have been doing adept patches during feisty as well as myself so there's people to help with thfat
=== Riddell wonders why people assume the KDE crash handler is called krash
05:39   mdz     I can't imagine why
05:39   dholbach        hehe :)
05:39   mdz     ...
05:39   kwwii   while we are on the subject, the apport icons (from the last meeting), a first version is ready and the final icons should be done soon
05:39   fabbione        ROFL
05:39   pitti   kwwii: Troy sent me some, they look really nice!
05:39   Keybuk  Riddell: you realise that it now has to be
05:40   mdz     pitti: ok, are you finished with your agenda item?
05:40   kwwii   pitti: exactly, I am going to touch them up a bit, but they will be done soon
05:40   pitti   mdz: so, the decision seems to be 'yes, we want it'?
05:40   Keybuk  yes please
05:40   pitti   mdz: ok, then I'll put it into the archive today and discuss integration with Riddell
05:40   mdz     pitti: of course we do; it's a question of whether we can get it finished soon enough
05:40   Riddell action: pitti to upload and riddell to evaluate that it doesn't break with current KDE stuff and find someone to do adept-updater work
05:40   pitti   ACTION: discuss adept-notifier integration of apport (pitti/Riddell)
05:41   pitti   heh, snap again
05:41   mdz     we already covered StopOnError earlier
05:41   mdz     (dholbach) [WWW]  https://lists.ubuntu.com/archives/ubuntu-devel/2007-February/023233.html
05:41   dholbach        I think we all agree, that it would have been nice to get this in earlier, I still wonder if it wouldn't make sense to get xorg 7.2 in still (in terms of maintainability and fixes we'd get from upstream and support for newer devices, etc.)
05:41   mdz     agenda items which consist solely of URLs are deprecated
05:41   pitti   does anyone know whether tepsipakki has the sk1llz for that?
05:41   dholbach        What does the Release team think?
05:42   mdz     dholbach: basically the same answer as for apport-qt
05:42   mdz     we certainly do want it, but we have finite resources and are occupied with other things at the moment
05:42   dholbach        mdz: I don't think we can have xorg7.2 in universe :)
05:42   cjwatson        on the one hand, I'd like to get the driver fixes, but on the other I'm concerned about having nobody dedicated to new bugs coming in
05:42   mdz     is anyone available to review his packages and upload them?
05:42   dholbach        cjwatson: we don't have anybody dedicated to old bugs atm too :-/
05:42   mdz     and who would be responsible for bug reports?
05:43   mdz     I assume this stuff isn't in Debian yet
05:43   cjwatson        we ought to be able to sync a number of the libraries from Debian experimental
05:43   mvo     I guess we could do this as a team effort (review+upload)
05:43   cjwatson        mdz: I think some of this is merges from experimental
05:43   tfheen  I'm not happy with it unless we have a bunch of interested people who works on it, actively.
05:43   cjwatson        but I haven't verified
05:43   seb128  I can review some uploads, I've enough bugs on my list without xorg though
05:44   tfheen  we have a bunch of people who can chip in a bit, but that's not really enough.
05:44   dholbach        cjwatson: he merged a bunch of packages with experimental already
05:44   tfheen  seb128: and you're already stretching more than last cycle now that you're doing ubuntu-archive stuff.
05:44   mdz     if we can get a plausible community effort behind it, we can do it
05:44   mdz     but someone in core-dev needs to be the point person for it
05:44   tfheen  mdz: that'd need to happen fairly quickly though.  If we have a team of interested people and merged packages in a week, it can happen.
05:44   seb128  tfheen: right, I clearly don't intend to spend much efforts on xorg
05:45   mdz     what's needed is to explain the requirements for making this happen for feisty, to the people working on it
05:45   cjwatson        somebody should post to -devel with such an explanation and calling for core-dev assistance
05:45   kylem   mdz, i'm willing to take point if i need to.
05:46   seb128  the question is if we think the 7.2 upload would bring bugs_fixed >  new_bugs_brough
05:46   cjwatson        if that came from one of the core team it would have more impact
05:46   tfheen  mdz: I can do that from a RM POV.
05:46   mdz     get a handle on the scope, estimate a reasonable deadline for completion, form a team which can plausibly respond to bug reports, etc.
05:46   kylem   i'm sure mjg59 will chip in too, he wants to see some of this stuff in feisty.
05:46   Keybuk  7.2 doesn't include either input-hotplug or monitor-hotplug/randr 1.2; right?
05:46   kylem   Keybuk, correct, that's 7.2.1 ;-)
05:46   tfheen  Keybuk: input-hotplug is easily mergable, but monitor-hotplug is 7.3, AIUI.
05:46   mdz     it surely brings heaps of hardware-related improvements though
05:46   kylem   still doable for feisty thoughh...
05:47   cjwatson        kylem: I don't want you doing much of the actual work, but I'd be happy if you're willing to coordinate
05:47   mvo     I would like to support the effort too
05:47   kylem   randr 1.2 needs xserver 1.2.1 which keithp has said he can have release ready for us...
05:47   cjwatson        some of the work will match up with your kernel bits of course
05:47   dholbach        I'll try to help with forming a team and talk to tepsipakki - should the team present their efforts at the next TB meeting or something?
05:47   kylem   cjwatson, right, i don't want to do the actual work either. ;-P
05:47   mdz     cjwatson: would you write up the requirements for ubuntu-devel?  formulate it so that someone needs to put their name in each of the necessary slots in order for it to be approved
05:47   fabbione        dholbach: there is an X team already
05:47   fabbione        dholbach: let's use that one
05:47   dholbach        fabbione: where?
05:47   cjwatson        it's modular. the team should get whatever the hell they can into the archive in incremental stages that won't break the world
05:47   mdz     ubuntu-x-swat
05:48   fabbione        dholbach: ubuntu-x-swat..
05:48   dholbach        yeah, but who's on that team?
05:48   cjwatson        not wait for a meeting :)
05:48   cjwatson        mdz: yes
05:48   kylem   cjwatson, i'm mostly just concerned about -intel for obvious reasons.
05:48   dholbach        I didn't to intend to invent a new name
05:48   cjwatson        right
05:48   mdz     ACTION: cjwatson to post requirements for X.org 7.2 in feisty to -devel
05:48   fabbione        dholbach: me... and a few others... people don't join it for fun
05:48   mdz     at a minimum, this should require that the packagers and a couple of other folks step up to join the X team and follow up
05:48   ogra    how do we make sure we dont need to roll back everything if they loose interest half way ?
05:48   mdz     and someone on -core-dev to sponsor them
05:49   cjwatson        ogra: 16:47 < cjwatson> it's modular. the team should get whatever the hell they can into the archive in incremental stages that won't break the world
05:49   mdz     and we get a commitment from them
05:49   ogra    cjwatson, but if it does ?
05:49   cjwatson        this should be perfectly doable; our client-side and server-side stuff is already out of sync
05:49   cjwatson        ogra: we only need to roll back a package or two
05:49   ogra    mdz, exactly, thats what i mean
05:49   dholbach        fabbione: we all agreed that we don't have somebody who looks after bugs at the moment... that's why I asked 'where' - I wrote the wiki pages for ubuntu-x-swat so I should know :)
05:49   cjwatson        I have many concerns, but they don't include needing to roll back everything
05:50   fabbione        dholbach: right, i thought you wanted to create another LP team
05:50   ogra    cjwatson, mine neither, but being left with a half done update ...
05:50   mdz     ok, sounds like consensus to me
05:50   dholbach        fabbione: no, not really
05:50   mdz     moving on
05:50   mdz     Keybuk: udev debugging?
05:50   Keybuk  still have to write that
05:50   cjwatson        ogra: half-done isn't actually all that bad in this case. Anyway, #ubuntu-devel
05:51   Keybuk  I'll try and get to it next week for the bug fixing push
05:51   iwj     udev debugging> shoot the author ?
05:51   iwj     Excuse me, I'm just a bit annoyed with it recently :-).
05:51   cjwatson        legal udev debugging
05:52   Keybuk  iwj: could you write up the problems you had with it
05:52   mdz     s/legal/helpful/
05:52   Keybuk  it could be a useful thing for upstream
05:52   seb128  mdz: is that ok if I go now? I've guitar class in a few min
05:52   Keybuk  kay's a nice guy, he accepts helpful (and/or witty) criticism
05:52   mdz     if done with a constructive tone
05:52   iwj     Keybuk: Hmm.  I'll write up a rant and then we can tone it down into something useful.
05:52   Keybuk  send it to me first; since I already have a working relationship with him
05:52   Keybuk  ok
05:52   Keybuk  ACTION iwj to write up summary of experiences debugging udev
05:52   iwj     While we're on udev, is anyone here affected by bug 83878 ?
Ubugtu  Malone bug 83878 in udev "wrong permissions for /dev/null" [High,Confirmed]  https://launchpad.net/bugs/83878
05:53   mdz     seb128: OK, but this meeting is scheduled for 1 hour, you should plan on being able to stay until the end
05:53   iwj     If so talk to me afterwards.
05:53   Keybuk  iwj: everyone is on and off; it tends to show up once in a while with a whole bunch of different causes
05:53   seb128  mdz: ok, will do for next time, thanks
05:53   mdz     sfllaw will e-mail distro-team@ about commercial package support
05:53   Keybuk  it's the most common symptom of "udevtrigger didn't get run"
05:53   iwj     Keybuk: Joy.
05:53   Keybuk  mdz: he's done that
05:53   mdz     this seems to have happened _during_ the meeting
05:53   cjwatson        hah
05:53   sfllaw  Yes.
05:53   cjwatson        Brinkmanship. :-)
05:53   sfllaw  I only noticed after reading the agenda.
05:54   Keybuk  iwj: sometimes caused by the udev init script being run multiple times
05:54   mdz     deliverables were mailed to distro-team after last week's meeting
05:54   cjwatson        doko to mail ubuntu-devel about which Python modules should be in main
05:54   cjwatson        judging from the odd /msg, doko has been investigating this today?
05:54   doko    cjwatson: that was done *before* the meeting
05:55   cjwatson        aha, I didn't notice; I'm behind on -devel
05:55   Keybuk  doko: reference?
05:55   Keybuk  doko: you didn't follow-up to distro-team to say the action was done
05:55   Keybuk  (which is useful if your line manager hasn't caught up on other mailing lists :p)
05:55   doko    Keybuk: hmm, ok
05:55   mdz     cjwatson to chase up the set of core-devs who can help moderate ubuntu-devel and arrange for clear documentation
05:56   cjwatson        FYI, I've edited Simon's late update into the agenda
05:56   doko    Keybuk: https://lists.ubuntu.com/archives/ubuntu-devel/2007-February/023235.html
05:56   mdz     I posted bullet points which should be sufficient for documentation
05:56   cjwatson        moderation> this is still not done, I'm afraid; I gave feature-freeze requirements precedence
05:56   Keybuk  heh, 20 seconds before the meeting doesn't count <g>
05:56   cjwatson        please leave it on my action list for this week
05:56   mdz     ok
05:56   mdz     tfheen: release readiness?
05:56   heno    I've done some moderation and have filed some RT about whitelisting and spam
05:57   tfheen  mdz: I'm a bit behind on looking at the spec status, but when I looked at it on Monday, it looked like about half the specs were good progress or better.
05:58   mdz     tfheen: blocker bugs?
05:58   Keybuk  I should probably have sent tollef the list of specs mdz and I wrote last week
05:59   tfheen  Keybuk: yes, please.
05:59   Keybuk  that has whether they're likely to meet FF, slip but make the release, or miss
05:59   tfheen  mdz: I'm behind on those as well, but I don't have any big problems on my radar.
05:59   mdz     I'm more interested in bugs, honestly
05:59   mdz     we can more easily release without a feature than with a major bug
06:00   tfheen  there's a fair amount of polishing to be done such as NetworkManager needing a bit of love to handle suspend/resume reliably.
06:00   mdz     tfheen: have you received any high-profile issues from sfllaw, bdmurray or others in the past week?
06:00   Keybuk  we should target bugs at the feisty release?  or at a milestone?
06:00   mdz     right, is there a process in place to flag bugs which you should be tracking?
06:00   tfheen  Keybuk: if they're feasible for a milestone, milestone.
06:00   Keybuk  https://bugs.launchpad.net/ubuntu/feisty/+bugs
06:01   Keybuk  (has three 3 bugs)
06:01   Keybuk  https://launchpad.net/ubuntu/+milestone/ubuntu-7.04
06:01   tfheen  mdz: not a formal one, no.  I'll get in touch with QA about it.
06:01   Keybuk  (has a whole bunch of bugs)
06:01   mdz     ACTION: tfheen to document bug escalation to release management
06:01   tfheen  so far it has been "target stuff to a release/milestone"
06:02   mdz     tfheen: plenty of room for confusion there, especially since we have milestones intended to work around the former lack of release targeting
06:02   mdz     ok, that's the end of the agenda
06:02   mdz     any other business?
06:02   tfheen  I'd just like to remind everybody that herd-4 is due next week
06:03   tfheen  and that we're now in FF+UVF, so please get in touch if you have new upstream versions you want in.
06:03   pitti   oh, already? *urgh*
06:03   tfheen  pitti: traditionally, it's been the start of the distro meeting, you've I've let it slip by a whole hour! :-)
06:03   cjwatson        I have migration-assistant still to land
06:03   BenC    what if I have a totally new package?
06:03   Keybuk  I still have both my specs to land
06:03   cjwatson        it's in main, but the ubiquity merge needs to be done
06:03   pitti   tfheen: I meant herd-4, not UVF
06:04   cjwatson        in the middle of that :)
06:04   tfheen  pitti: oh, ok.
06:04   BenC    new kernel needs dtc (device-tree compiler) for ppc
06:04   tfheen  I'm fine with people sneaking stuff in under the wire for today.
06:04   tfheen  BenC: ugh.  Get it packaged ASAP.
06:04   sfllaw  tfheen: I have a version of ttf-dejavu that I'm looking at building.
06:04   tfheen  BenC: and get the MIR done ASAP.
06:04   sfllaw  To solve internationalization issues.
06:04   BenC    tfheen: will do
06:04   BenC    I might just sneak it into the kernel build, since that's the only place that needs it
06:05   tfheen  BenC: please don't, I'd rather have to NEW it.
06:05   BenC    then it'd only take up src space
06:05   BenC    tfheen: let's talk in -devel
06:05   mdz     ok, anything else, please follow up by mail/IRC
06:05   mdz     adjourned, thanks all