UbuntuDev-2007-02-15
TZ UTC +1
09:46 mdz good evening
09:46 ajmitch hi mdz
09:47 ajmitch devel team meeting, is it?
09:51 mdz ajmitch: yes
09:52 mdz roll call
09:53 bdmurray present
09:53 _kyle batman! er. nope, just me.
09:53 Riddell hola
09:53 rtg here
09:53 _kyle (connected xchat since my ssh is all laggy)
09:53 kwwii howdy all
09:55 mvo__ hello
09:55 mdz cjwatson,heno,doko,BenC,pkl,asac,tkamppeter,Keybuk,pitti,fabbione,tfheen,iwj,ogra: ping
09:55 doko pong
09:55 heno pong
=== ogra waves
09:56 Keybuk _o/
09:56 asac hi
09:56 pitti hello
09:57 cjwatson here, just making coffee
09:58 mdz BenC: is pkl around?
09:59 BenC mdz: checking
09:59 tfheen pong
09:59 BenC cjwatson: coffee, sounds good
09:59 mdz cjwatson: expecting till?
09:59 mdz fabbione: ping
10:00 BenC he's coming
10:01 fabbione pong
10:01 fabbione sorry i am late
10:00 mdz ok, moving along
10:01 mdz rtg: you started last week, but this is your first weekly meeting. welcome!
10:01 asac rtg: hi!
10:01 rtg Thanks.
10:01 Riddell hi rtg
10:01 mdz rtg is Tim Gardner, who I believe remains the newest addition to the kernel team
10:02 mdz agenda is at https://wiki.ubuntu.com/DevelTeamMeeting20070215
10:02 mdz any last-minute additions?
10:02 cjwatson mdz: Till didn't say he wasn't coming
10:03 mdz ok, moving right along
10:03 mdz pitti: you're up
10:03 pitti #
10:03 pitti Do we want to use XSBC-Original-Maintainer (which works, modulo the small bug fix that is already prepared), or teach dpkg about a proper 'Original-Maintainer:' field?
10:03 mdz there was some discussion about this by mail
10:03 pitti so, the point is, XSBC- looks ugly, but works
10:04 iwj We should use XSBC- for at least the next while, as I say.
10:04 pitti the .debs, .dsc etc. have Original-Maintainer, so for users it's fine
10:04 tfheen adding the field is trivial, but I don't know if Debian will take it.
10:04 iwj Well, let's offer them the patch and if and when they take it and it's widely deployed we can switch to it.
10:04 pitti so the effect won't change if we later teach dpkg about the new field
10:04 tfheen iwj: why? If we actually think it's a good idea, we should just go with O-M, IMO.
10:04 iwj There's no harm of XSBC- in the meantime except that it's slightly ugly.
10:04 iwj tfheen: Because people often run source-processing tools not on the distrorelease.
=== pitti agrees to iwj here, especially if we have tool support for making these changes
10:05 iwj ... that they are intended for.
10:05 iwj I said all this by email ...
10:05 cjwatson where was this e-mail conversation?
10:05 tfheen distro-team@, iirc
10:05 pitti replies to my activity report
10:05 cjwatson ah, yes
10:05 iwj Should it have been in ubuntu-devel ?
10:06 cjwatson OTOH, failing to use XSBC- only has the consequence of an ugly error message, not build failures, IIRC
10:06 tfheen cjwatson: correct.
10:06 mdz iwj: yes
10:06 iwj mdz: OK
10:06 pitti cjwatson: and that the field doesn't actually appear in the debs/dsc?
10:06 tfheen iwj: then I say we can just add it to our dpkg and those who don't use our dpkg can use XSBC-.
10:06 cjwatson pitti: sure, but whatever
10:06 iwj cjwatson: Err, using O-M when the tool doesn't support it means the field gets lost.
10:06 pitti cjwatson: but that'd miss the point?
10:06 cjwatson iwj: does that actually matter?
10:06 cjwatson all we've promised to do is have it in our archive
10:06 iwj tfheen: But the question is _what do we put in our packages_, which other people besides us touch too.
10:06 tfheen pitti: the debs will be fine as they're built on the autobuilder.
10:07 mdz there's no reason to use O-M in Debian
10:07 pitti right, just .dsc
10:07 cjwatson it makes no technical difference to the package
10:07 iwj cjwatson: All universe maintainers are now to be forbidden from running dpkg-foobarpackage other than on feisty ?
10:07 cjwatson oh, that's true, it would make a difference to the .dsc
10:07 cjwatson in that case I agree with Ian
10:07 mdz iwj: do you develop on Feisty?
10:07 iwj mdz: Yes, but I run dpkg-signchanges on sarge.
10:08 tfheen signchanges is irrelevant; -gencontrol is the interesting one.
10:08 iwj tfheen: Yes, but this is turning into a complex set of rules that everyone has to get right.
10:08 cjwatson I have in the past built Ubuntu source packages on Debian (quite regularly) and I see no reason why we should break that
10:08 iwj XSBC- just works and we should use it.
10:08 tfheen except it doesn't work correctly due to a bug?
10:08 iwj What cjwatson said. Sometimes I don't have a feisty install to hand.
10:09 pitti tfheen: I have fixed that in my pending upload
10:09 iwj tfheen: The bug we can get fixed in etch even probably.
10:09 pitti well, cjwatson did the fix
10:09 tfheen pitti: oh sure, but the "you can't build packages on !feisty" argument applies until it actually is in other stable releases.
10:09 pitti tfheen: but the bug is irrelevant mostly, it only affects propagation to .debs, not to .dsc
10:10 tfheen "can't" here meaning "will not have a 100% compliant .dsc", nothing will actually break.
10:10 pitti tfheen: irrelevant for building source packages, that is
10:10 iwj And why oh why oh why are we having this argument by IRC ?? IRC is a terrible medium for arguments.
10:10 tfheen pitti: oh, ok.
=== pitti actually prefers discussing stuff synchronously
=== ogra too
=== tfheen prefers IRC over email any day.
10:10 cjwatson I'm not hearing serious objections to XSBC-
10:11 pitti I'm still in favour of eventually supporting O-M, but that's something for later
10:11 cjwatson so I think we should do that and move on to the next of the several items on the agenda
10:11 cjwatson pitti: sure
10:11 iwj pitti: Yes.
10:11 cjwatson * Can we find a sane method that dch can use to tell apart main from universe packages? If so, we could add an automatic change of [Original-] Maintainer:.
10:11 pitti great
10:11 cjwatson mdz addressed that on distro-team@
10:11 iwj mdz was right.
10:12 pitti ok, so we set it to $DEBEMAIL?
10:12 pitti and warn if it's not m/ubuntu/?
10:12 cjwatson no, leave it alone
10:12 Riddell pitti: or kubuntu or edubuntu...
10:13 cjwatson often you want it to be the relevant team mailing list instead
10:13 pitti cjwatson: my q is about doing something if there's no O-M
10:13 pitti I'm fine with fixing it manually, it's just a bit cumbersome
10:13 pitti and, as doko noticed, pro/demotions will break the default ML values
10:14 cjwatson I don't think we should mess with debian/control (or even Maintainer in the .dsc) automatically. It's far too fragile.
10:14 cjwatson doko's point is valid but later on the agenda :-)
10:14 doko heh
10:14 pitti it's just closely coupled
10:14 pitti anyway, if noone is in favor of automatic changing, lets go on
10:15 cjwatson For main packages, should we rather use ubuntu-devel-discuss@ instead of ubuntu-devel@? If so, we need to change and sign off the spec.
10:15 cjwatson addressed on distro-team@ (yes)
10:15 cjwatson Do we need to get all packages fixed in Feisty? IOW, do we need mass-uploads or can we just slowly migrate the fields over time?
10:15 pitti that's done
10:15 cjwatson also addressed on distro-team@
10:15 cjwatson handling of addresses where source/binary are in different pockets; CORE address for packages in universe.
10:15 pitti not really
10:15 Keybuk some packages built in feisty do not have equivalents in Debian
10:15 cjwatson not really to which?
10:15 pitti I'd really like to discuss the schedule here
10:15 Keybuk so automatic modification would be wrong in that case
10:15 iwj If we do nothing special, all the packages will be updated by feisty+1, right ?
10:15 pitti cjwatson: slow/quick migration
10:16 pitti iwj: we need to modify debian/control, that won't happen automagically
10:16 pitti so, mdz and I had the compromise of fixing all 350-some main .debs for feisty
10:16 cjwatson I'm with mdz on this; we are way behind on our commitment and we need to get it done
10:16 iwj All of the .debs will be updated and not all of the .dscs, then ?
10:17 pitti and do the source-only and universe ones with the feisty+1 merge
10:17 tfheen iwj: not magically, no. Just through churn.
10:17 pitti I think that's fair
10:17 pitti we have 750 main and > 1000 universe sources which need to be modified, and rebuilt by beta otherwise
10:18 pitti and if we get new X.org packages anyway, a good chunk of the 350 .debs will already be sorted out
10:18 mdz the source maintainer is much less visible, and unlikely to be noticed by users reporting problems with the package
10:18 pitti (explanation: fixing the .debs is a matter of pure rebuild)
10:18 mdz which is the source of the complaint
10:18 pitti so we'd get the dpkg-source check into feisty now, so that we do not continue to upload sources with wrong maintainers
10:19 mdz so fixing the remaining .debs is a solid incremental step toward finishing the job
10:19 mdz as is fixing dpkg-source
10:20 pitti ok, if we don't have further comments, I'll care for the rebuilds and take doko's gcc changes into account
10:21 cjwatson ok
10:21 cjwatson * handling of addresses where source/binary are in different pockets; CORE address for packages in universe.
10:21 pitti doko: ^ you need some rebuilds?
10:21 Riddell win 12
10:21 pitti I think for this only source packages matter
10:21 Riddell erk
10:21 cjwatson source/binary is irrelevant, as discussed on the list
10:21 doko pitti: yes, I'll send you the list; please start after GCC-4.1.2 is in the archive
10:21 pitti doko: ETA?
10:22 doko after the freeze ends. tfheen ?
10:22 pitti doko: ah, that's fine
10:22 cjwatson * Promotion/demotion invalidates the address.
10:22 mdz regarding promotion/demotion, I'm personally not fussed
10:22 cjwatson I suggest that somebody write a tool which points out the inconsistencies, and we can garden it from time to time
10:23 mdz this is much more about masking the original address than providing the best contact
10:23 cjwatson much like the other such tools we already have
10:23 pitti if people set it manually anyway, then we hopefully will get more specialized teams or individual maintainers anyway
10:23 cjwatson but I agree it is not urgent
10:23 tfheen doko: freeze ends tonight; It seems the current set of ISOs is good, so I'll release them tonight and thaw the archive, then send out the announcement tomorrow morning.
10:23 mdz they'll be fixed when rebuilt
10:23 pitti we actually need to rebuild such packages anyway for translation changes
10:23 mdz ok then, it's only an issue for the source, so even less urgent to change things
10:23 doko tfheen: just ping me when I can upload (if it's before bedtime)
10:24 mdz so we're all clear on debian-maintainer-field now?
10:24 pitti yes, sorry for the abundance of questions
10:24 pitti but this affects so many packages that we should get it right at the first shot
10:25 mdz agreed, thanks
10:25 mdz pitti: I answered you about apport-retrace on the list; I think it's very useful, but we're behind on a few higher-priority items where you might be able to help out if you have spare cycles
10:25 pitti right, got that
10:25 mdz pitti: did you already talk with Scott about your tasks?
10:25 pitti spare cycles go into bug fixing, but I'm happy to help out with specs where appropriate
10:26 pitti mdz: not yet, I was away in the evening, sorry
10:26 cjwatson * ISO release testing (Henrik Omma): I think we should decide before Beta whether we are going to actually use the Malone-based tracker. Are people comfortable with it or is the wiki better after all? Simon, Tollef: are you two leading beta release/testing together or do I have a key part in this (beyond the community-based contribution)?
10:27 Riddell it works well enough from my point of view
10:27 heno It seems to have worked fairly well today
10:27 pitti personally I found the wiki much better for getting an overview of the overall state, but bugs parallelize better
10:27 ogra ++
10:27 cjwatson heno: on the latter item, I'd like you to lead the testing side of this, since you've been making good progress with it so far
10:27 heno that is true
10:27 tfheen I'm much happier this time than the previous time.
10:27 cjwatson heno: let's talk about that on the phone tomorrow?
10:28 cjwatson tfheen: are bug comments from individual testers getting through to you effectively?
10:28 heno cjwatson: ok, s long as it's clear that I'm doing it
10:28 mdz pitti: can you think of a way to improve the overview using the bugs?
10:28 heno cjwatson: sure
10:28 tfheen cjwatson: we haven't really had many individual testers, but yes, I have subscribed to the product.
10:28 cjwatson heno: thanks, I appreciate it
10:28 pitti mdz: we could use bughelper to create a report
10:28 mdz heno described a scheme using the status field to provide a sort of overview, though of course it requires someone to maintain the state
10:28 ogra mdz, a generated table overview ?
10:29 heno people who post a result can update the state
10:29 ogra that would need to parse the bugtexts though
10:29 heno wejust need good etting of testers
10:29 cjwatson heno: I don't think that will happen in practice
10:29 tfheen pitti: I need to chat a bit with dholbach about bughelper, I guess; I really want to generate reports from malone and can't today.
10:29 pitti a mere matrix with the current bug states would already be helpful, I figure
10:29 heno to make sure they are clued in and committed
10:29 tfheen not just for ISO testing, but also for other release metics.
10:29 cjwatson and it would be best if the amount of education of testers required is as small as possible
10:30 mdz I don't see how bughelper helps, can you explain?
10:30 heno I envision just a small group of 'trusted' community testers this cycle
10:31 heno mdz: it can scrape useful state info from the bug pages
10:31 cjwatson I'm worried that we'll swamp a small group; it's a lot of work even for full-time staff
10:31 pitti mdz: I meant, using the bughelper library to find the bugs and get their states, and then cobbling together some HTML report
10:31 heno and present them in an html table
10:31 pitti heno: :)
10:32 tfheen cjwatson: yes, it should be possible to just jump in and test a single ISO without having to go through a big process to do so.
10:32 mdz what would that tell you which wouldn't be visible from the table on the iso tracker bug page?
10:32 heno so we get a non-editable 'wiki' page powered by the malone content
10:32 ogra the problem is that finer grained info like the different install variants is only in the bugtexts
10:32 pitti mdz: we could count number of testers, parse out the ok/fail comments, parse out bug numbers to make them clickable, etc.
10:32 tfheen mdz: the malone bug page is going to be unwieldy when we have the full test cases there, as we will for beta, RC and release.
10:33 heno ogra: no we will do separate bugs for those in later milestones
10:33 ogra ah, cool
10:33 mdz pitti: oh, I see, using the format conventions described in the docs
10:33 mdz it looked like some people were using those at least
10:33 heno so there will be very many tracker bugs
10:33 heno so an overview html page is a must really
10:33 mdz tfheen: no more unwieldy than the wiki page, and probably less
10:34 heno I think it would be worse tha the wiki
10:34 heno unless you filter by tags
10:34 pitti . o O { using an apport GUI to create a report with parseable standard syntax, yummy }
10:34 cjwatson perhaps we can brainstorm mad ideas by mail? :-)
10:34 heno but the bughelper hack should be easy
10:34 heno yep
10:35 heno I'll prepare something
10:35 tfheen but as I said, I'd really like to be able to pull statistics out of malone since I can't today and I'd love to for a release status page.
10:35 heno (email with ideas)
10:35 cjwatson ACTION: heno, tfheen, pitti etc. to discuss and prepare status overview page for ISO tests
10:35 heno tfheen: that's doable
10:35 heno ok, done :)
10:36 mdz [UbuntuSpec] increase-hwdb-participation (Sebastien Bacher): do we need a menu item for hwdb participation? that's something that is likely to be launched once only and will clutter the menu then
10:36 mdz the point here is that we want it to be obvious how to contribute to the database
10:36 seb128 and we want to keep the menus or shell not too long if possible
10:36 pitti heads-up: right now we have an one-time notification pointing people to the menu item
10:36 mdz and we do want people to contribute again if their hardware changes
10:36 seb128 because many items make them hard to use
10:36 ogra we discussed that the other day in -devel ... the most proper solution (having a button in the notofocation) braks the notofocation policy
10:36 pitti we can easily point people somewhere else
10:37 ogra meh ...
10:37 seb128 well, there is a button to do that to hal-device-manager
=== ogra goes for a typing course
10:37 kwwii why not put it in System-->Administration ?
10:37 mdz seb128: no one knows that is there
10:37 pitti no, no button in the notification, that'd be wrong
10:37 seb128 we can point people to h-d-m
10:37 ogra right
10:37 seb128 mdz: we display a notification bubble if I understood that correctly
10:37 ogra without the control center i agree ...
10:37 seb128 mdz: we could point people to hal-device-manager
10:37 tfheen seb128: yes, we do that today already.
10:37 mvo we already have a lot of icons in the control-center, I don't think it will get worse
10:37 ogra yep we do
10:37 heno we could mention it on the default firefox homepage
10:38 seb128 mvo: we try to reduce the list
10:38 heno (if people look at that)
=== mvo is not sure if people actually read that ff page
10:38 seb128 mvo: we should not start accepting random icons because the list is already long, that's not a reason to make it longer
10:39 pitti another option is to just open hwdb-client right away on first login
10:39 seb128 what would be wrong with pointing people to h-d-m?
10:39 cjwatson pitti: ugh
10:39 pitti but I understand that contradicts our 'no wizards' policy
10:39 ogra i'm not opposing to point to h-d-m ... if users dont have to wait for control-center and have to search there
10:39 mvo I think the new g-c-c concept does not work very well, but that is a different discussion
10:39 mdz heno: that's not a bad idea
10:39 pitti cjwatson: ugh indeed :/
10:39 seb128 grrraa
10:39 heno I agree with seb128 on this, and icon for a one-time item is a bit much
10:39 seb128 please stop the constant ranting on the shell
10:39 seb128 I already said we will switch back to menu
10:39 tfheen seb128: I think the new shell is much better.
10:39 mdz to return to the issue at hand...
10:39 heno we could make it quite prominent on the FF page
10:39 seb128 (that's especially for ogra and mvo who keep telling that every day)
=== mvo hugs seb128
10:40 pitti heno: you just cannot open programs with HTML links
10:40 ogra right ..., thats why i'm not opposed to drop the menu item completely
10:40 mdz we're concerned with the use case "I want to submit my system profile to the Ubuntu hardware database"
10:40 ogra seb128, ^^^
10:40 pitti ogra: people have to find it again if HW changes
10:40 seb128 tfheen: it still has some bugs and could be faster, it's likely to be default upstream next cycle
10:40 heno pitti: right but you can show a screenshot with colourful arrows :)
10:40 ogra pitti, but then they have seen it once at least
=== pitti thinks that in fact most of the things in c-c will only be used once, so *shrug*
10:41 seb128 mdz: well, that mean the menu item will be used like once a year (you don't change config every week usually)
10:41 seb128 mdz: and it'll be in the way the rest of the time
10:41 heno pitti: actually you can, with a custom mime-type
10:41 mdz seb128: agreed, it's rarely used
10:41 pitti seb128: neither do users change their theme or keyboard layout
10:41 seb128 pitti: those are configuration tools
10:41 pitti heno: urgh :)
10:42 seb128 pitti: and people might play with theme more often than you think
10:42 heno filename.launch-hwdb :)
10:42 pitti seb128: sure
10:42 seb128 but that's not the point
10:42 mdz seb128: the data we collect from it is very important, and if users don't see it, they don't participate. I agree with your concerns about the menu, but how else can we present it where users will discover it?
10:42 seb128 I'm just trying to keep the list of menu or shell items not too long
10:42 pitti another idea:
10:43 seb128 mdz: we have a notify bubble, pointing them to hwdb menu item or hal-device-manager is about the same no?
10:43 pitti how'bout adding it to update-notifier? people would get a tray icon and if they click on it, it'd open h-c, and then the icon would disappear
10:43 mvo we could do it as a post-install note
10:43 seb128 mdz: h-d-m is also to the menu and it has a button to run hwdb-client
10:43 heno can we make it very prominent during testing and much less at release time?
10:43 mvo u-n has support for this already
10:43 mvo it can even include scripts
10:43 ogra i really think it doesnt needed an extra menu entry ... and if i remember correctly that was the initial polcy when mdz assigned the project to me ...
10:43 tfheen pitti: and then readd the icon if the hardware changes?
10:43 pitti tfheen: that's harder
10:44 ogra i had a bunch of whishlist bugs that made it appear
10:44 heno the people who run feisty are the most likely to participate anyway
10:44 seb128 pitti: well, that's what I said before, use a notification area icon, that would work too
10:44 tfheen pitti: not really; store a md5sum of the lspci output or something somewhere and check that on login.
10:44 pitti tfheen: but it would bring people to it once, and then we can hide it behind h-d-m and explain where it is in the icon notificatino
10:44 mdz ogra: it originally had a menu entry; it was removed during one of the menu cleanups
10:44 pitti tfheen: and usb, and there it gets trickier
10:45 mdz pitti: isn't that what the increase-hwdb-participation spec was meant to be?
10:45 ogra mdz, the first hoary version only had the h-d-m button ... in breezy i added the menu entry mainly because kubuntu complained ...
10:45 mdz pitti: notify the user once?
10:45 pitti mdz: it talks about a notification, not a tray applet
10:45 heno When we get a slideshow in ubiquity we can show it there
10:45 mvo pitti: we have the post-install notifications in u-n, we could use those
10:45 pitti mdz: from a notification we cannot launch programs, but from a tray icon we can
10:45 mvo they are there and ready (and support scripts)
10:46 pitti well, we can launch programs from notifications, but it is *very* ugly usability-wise
10:46 cjwatson this item is dragging on somewhat
10:46 mvo the u-n post-install hooks have a dialog that contains a button. nice text + button
10:46 seb128 let's use that then
10:46 pitti mvo: sounds good
10:46 tfheen a problem with regular notifications is they disappear, so if you don't pay attention, they go away and you can't get them back
10:46 tfheen so interacting with notifications is bad.
10:46 mdz so long as the user is inivted to participate when they install, I'm happy
10:47 mdz either launching the client directly or providing simple instructions
10:47 mvo pitti: lets check this out tomorrow together, ok?
10:47 pitti mvo: yes
10:47 mdz opening device manager and finding the button is not simple enough, though
10:47 mdz ACTION: mvo/pitti to review options for hwdb notifications
10:47 mdz moving on
10:47 pitti mdz: the install note could explain where it is
10:47 mdz Maintenance "costs" of python debug packages (Matthias Klose)
10:48 pitti (this was about maintaining a large delta from Debian for the -dbg packages, since Debian is frozen ATM, and hasn't decided yet whether to adopt it)
10:49 pitti and the debian/rules code for that is nontrivial
10:49 pitti doko: ping ^
10:50 doko yes, the thing is, if we want/can afford it. it's a diff for every package we want to build extensions
10:50 doko in debug mode.
10:50 cjwatson I thought we had discussed this already
10:50 mdz I'm afraid I don't have the context
10:50 cjwatson how many packages are involved?
10:50 doko about 50 in main
10:50 cjwatson in fact I'm sure I spoke with you about this before and said yes
10:50 mdz oh, this is for debug packages for extension modules?
10:50 cjwatson 50? yes
10:50 doko ok
10:50 mdz why doesn't the autobuild infrastructure handle that?
10:50 cjwatson mdz: needs two build passes
10:50 mdz oh, right
10:50 doko debug mode needs a separate compilation
10:51 mdz ok, sounds like this has been resolved anyawy
10:51 mdz anyway
10:51 mdz Document bug escalation to release team (Tollef Fog Heen): Started, but I want to agree with Simon about it before writing it down on the wiki.
10:51 mdz this sounds like an action, not an agenda item
10:51 doko ok, was just brought up today on #u-d
10:51 mdz anything to discuss?
10:51 mdz tfheen: ?
10:51 tfheen mdz: no, I'm not sure why it ended up on the agenda.
10:51 cjwatson tfheen: write it down first, then discuss it. :-)
10:51 mdz ok, moving on
10:51 tfheen I should have taken it off; sorry.
10:51 cjwatson scott's/my fault for it ending up there.
10:51 mdz iwj/asac/pitti: firefox ready to go?
10:52 asac waiting for unfreeze
10:52 iwj I spoke to asac in quite a bit of detail.
10:52 Keybuk tfheen: you listed it under "Agenda Items" :p
10:52 asac i will go one more time and polish changelog but then pitti will sponsor upload :)
10:52 tfheen Keybuk: I must have been asleep; sorry.
10:52 cjwatson asac: (you don't need to wait for the freeze to end in order to have an upload made)
10:52 mdz asac: note that it can be uploaded during the freeze, and will just wait in the queue
10:53 mdz in fact that's preferred
10:53 pitti asac: will do after the meeting
10:53 asac hmmm ... thanks ... didn't know that ... misunderstood pitti then :)
10:53 cjwatson the queue in question is visible at http://people.ubuntu.com/~tfheen/unapproved-queue/feisty/
10:53 mdz ACTION: upload firefox (pitti, asac)
10:53 tfheen Keybuk: actually, it was under "action items", not "agenda". :-P
10:53 mdz discuss adept-notifier integration of apport (pitti/Riddell)
10:54 pitti so, we did that, and Riddel meant, that it should be fairly straightforward to port the update-notifier code to adept-notifier
10:54 mdz has that happened?
10:54 Riddell nope
10:54 pitti and we definitively want to have it done
10:54 Riddell it's on my todo for next week
10:54 pitti mdz: the discussion, yes, not the porting
10:54 mdz Riddell: I meant the discussion
10:54 Riddell oh, yes, we discussed
10:54 mdz ok
10:55 Keybuk tfheen: sorry, then it was me that was asleep :p
10:55 Riddell and apport is on the herd 4 CDs
10:55 mdz iwj to write up summary of experiences debugging udev
10:55 iwj udev> I haven't made a proper writeup but I have a few replies to bug reports which document some of the udev debugging procedures and which would make a reasonable source text.
10:55 mdz Keybuk: ^^ I thought that was your todo?
10:55 Keybuk mdz: I asked iwj to summarise his thoughts as well
10:55 iwj He palmed it off on me, since I, err, volunteered.
10:55 mdz ah, ok
10:55 Keybuk more as a "how can we improve this?" rather than "what to do"
10:55 Keybuk the "what to do" is still mine
10:56 mdz and we already reviewed the bug escalation item
10:56 mdz tfheen: release readiness?
10:56 Riddell I'm good except for powerpc CDs
10:57 Riddell but I believe that's the case for ubuntu and edubuntu too
10:57 ogra me too except one ppc kernel bug
10:57 mdz oh, speaking of powerpc
10:57 mdz those are no longer release blockers ;-)
10:57 Riddell so we don't care :)
10:57 tfheen mdz: I'm putting together a list of indicators on how ready we are (bug trends, oversizedness, etc) which I am going to put into some tool and put that on a web page somewhere.
10:57 Keybuk <mdz> with all due respect, ...
10:57 tfheen I don't have any numbers to give you, but the current state is looking good.
10:58 tfheen herd 4 is slightly delayed, but this is due to external factors, not bugs popping up in the distro.
10:58 Keybuk the bit where they forgot to turn Soyuz back on?
10:58 tfheen slightly as in I am doing the release now and not 12 hours ago.
10:58 Keybuk or something else?
10:58 tfheen Keybuk: yes, that bit in particular.
10:58 mdz what's needed in terms of infrastructure changes for the powerpc transition?
10:58 mdz cdimage bits?
10:59 cjwatson we're going to start considering powerpc as part of ports, yes?
10:59 tfheen I'm not sure; Colin knows that bit of cdimage much better than I since he set it up.
10:59 fabbione moving ppc to ports as of debs is not going to be easy
10:59 cjwatson also actually moving it to ports.ubuntu.com, which will be Hard
10:59 fabbione cjwatson: probably impossible any time soon
10:59 cjwatson because that requires per-release mirroring
10:59 mdz cjwatson: yes
10:59 cjwatson fabbione: it's not impossible, it's just work
11:00 mdz I don't see any hurry with the .debs
11:00 fabbione cjwatson: it's difficult for how it works now
11:00 cjwatson fabbione: "impossible" means "cannot be done even if work goes into it". Don't exaggerate.
11:00 mdz but we should move it out of the standard cdimage set
11:00 cjwatson that's fairly easy
11:00 fabbione cjwatson: the split at the moment is done with 2 rsync set of filters and not via dists/.. so it's difficult at the moment
11:01 cjwatson yes, i.e. "work"
11:01 cjwatson ACTION: cjwatson to move powerpc out of standard cdimage set
11:01 cjwatson (ten minutes)
11:01 tfheen cjwatson: If possible, I'd like to do it together with you.
11:02 cjwatson sure
11:02 cjwatson Keybuk: ^-- add tfheen to that
11:02 tfheen I know the basic bits of cdimage, but knowing it better is good.
11:02 cjwatson (assuming you're collecting items)
11:02 cjwatson * Other business
11:02 Keybuk cjwatson: yup
11:02 mdz anything else outstanding?
11:03 BenC big pat on the back to everyone
11:03 mdz ok, thanks everyone and good night
11:03 seb128 thank you mdz
11:03 mdz onward and upward
11:03 pitti thanks, fellows
11:03 asac thanks ... good night!
11:03 mvo good night!
11:03 ogra thanks
11:03 BenC thanks everyone!
11:03 seb128 'night
11:03 cjwatson next time let's have less discussion in the meeting. :-)
11:03 fabbione night everyone
11:04 pkl_ good night
11:04 doko good night
11:04 kwwii night all...that was, erm, fun
11:04 bdmurray night allMeetingLogs/UbuntuDev-2007-02-15 (last edited 2008-08-06 16:59:45 by localhost)