[01:29] <dungodung> :(
[01:31] <superuser> :(
[01:32] <dungodung> well, I won't miss much... I'm an op on a minor, peripheral channel
[01:33] <Hobbsee> @schedule sydney
[01:33] <Ubugtu> Schedule for Australia/Sydney: 15 Feb 16:00: IRC Operators | 16 Feb 08:00: Ubuntu Development Team | 18 Feb 02:00: Xubuntu | 21 Feb 23:00: Edubuntu | 23 Feb 03:00: Ubuntu Development Team | 25 Feb 04:00: Ubuntu US LoCo Team Mentor
[01:34] <Hobbsee> oh, 4pm....
[02:48] <beuno> @Buenos Aires
[02:49] <beuno> @BuenosAires
[02:49] <beuno> now, how did that work..
[02:49] <dungodung|sleep> @schedule Buenos Aires
[02:49] <Ubugtu> Schedule for America/Argentina/Buenos_Aires: 15 Feb 02:00: IRC Operators | 15 Feb 18:00: Ubuntu Development Team | 17 Feb 12:00: Xubuntu | 21 Feb 09:00: Edubuntu | 22 Feb 13:00: Ubuntu Development Team | 24 Feb 14:00: Ubuntu US LoCo Team Mentor
[02:49] <beuno> thank you very much dungodung|sleep
[02:50] <dungodung|sleep> np. sleep now
[06:01] <elkbuntu> can i request we wait 5 mins please. i've only just got home and i need to get a drink
[06:02] <Hobbsee> elkbuntu: sure.  until Seveas actually materializes, we cant do much anyway
[06:02] <elkbuntu> this is true
[06:05] <mneptok> we could start the dumming and watch fires.
[06:05] <mneptok> +r
[06:06] <mneptok> well, "duwwing," too.
[06:06] <Madpilot> I see that mneptok is using his Keyboard of Incoherency this evening. That'll make the meeting more interesting.
[06:07] <Hobbsee> doesnt he always, though?
[06:07] <Madpilot> sometimes he's just pasting song lyrics
[06:07] <ajmitch> oh there's a meeting
[06:10] <mneptok> sorry. the "keyboard of incoherency" was actually "keyboard with a penny in it"
[06:10] <Madpilot> ajmitch, eventually it will be a meeting. Currently it's just overflow from the den of insanity that is #ubuntu-ops
[06:11] <Hobbsee> hah
[06:11] <ajmitch> Madpilot: that's ok, I used to lurk in there as well
[06:11] <mneptok> Hobbsee: when are you putting that stick under a CC license?
[06:11] <Madpilot> oh, and I'll thank the Academy, too. Apparently it's the done thing.
[06:12] <Hobbsee> mneptok: godo question
[06:12] <Madpilot> it's LPSoD licensed, isn't it?
[06:13] <ajmitch> sigh, licence proliferation
[06:13] <mneptok> you were just attacked with a trademarked stick
[06:14] <Madpilot> LPSoDL - the Long Pointy Stick of DOOM License
[06:15] <mneptok> copyrightintoyourhead
[06:16] <Madpilot> we're spamming -meeting, aren't we?
[06:16] <elkbuntu> yep
[06:17] <ajmitch> nalioth!
[06:17] <nalioth> ajmitch!
[06:17] <sid> elkbuntu: Did those poll results ever go public?
[06:18] <elkbuntu> sid, not yet. this is not an appropriate place to discuss it either
[06:48] <Jucato> oh?
[06:48] <Jucato> oops sorry
[11:20] <dungodung> so it wasn't a big meeting, I see
[03:16] <tsmithe> boredandblogging, hi. what's your blog address, then?
[03:16] <boredandblogging> http://boredandblogging.com
[03:16] <boredandblogging> nothing worthwhile though, lol
[09:46] <mdz> good evening
[09:46] <ajmitch> hi mdz
[09:47] <ajmitch> devel team meeting, is it?
[09:48] <pochu> @now
[09:48] <Ubugtu> Current time in Etc/UTC: February 15 2007, 20:48:40 - Next meeting: Ubuntu Development Team in 11 minutes
[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
[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: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] <fabbione> pong
[10:01] <pitti> hello rtg!
[10:01] <fabbione> sorry i am late
[10:01] <mdz> rtg is Tim Gardner, who I believe remains the newest addition to the kernel team
[10:02] <ogra> hey rtg
[10:02] <mvo> hello!
[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.
[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.
[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
[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)
[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)
[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
[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.
 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 all