[06:48] <calc> hi
[06:50] <cjwatson> good morning
[06:50] <TheMuso> Greetings all.
[06:51]  * asac waves
[06:51] <ArneGoetje> hi
[06:51] <evand> hi
[06:53] <bryce> heya
[06:53] <calc> openoffice.org 2.4.0-3ubuntu1 is in hardy now :)
[06:54] <calc> waiting on translate-toolkit to be sync'd
[06:55] <james_w> morning all
[06:56] <ogra_cmpc_> *yawn*
[06:56] <ogra_cmpc_> morning
[06:57] <doko> good morning
[07:00]  * cjwatson counts on his fingers
[07:00] <cjwatson> I think that's everyone
[07:00] <cjwatson> so good morning everyone; hope you all had a good week while I was on holiday
[07:01] <slangasek> morning :)
[07:01] <cjwatson> this week, I largely want to do a checkup to ensure that we're on track for release, as there isn't all that long to go
[07:02] <cjwatson> though before we start, a quick reminder: please can everyone have another look at Daniel's sponsoring overview and make sure you're up to date there
[07:02] <cjwatson> (I have a few items myself)
[07:03] <cjwatson> https://launchpad.net/ubuntu/+milestone/ubuntu-8.04 is slightly alarmingly long
[07:04]  * calc has quite a few bugs to work on still but didn't milestone them
[07:04] <slangasek> yes; even discounting the bugs that are already fix-released
[07:04] <cjwatson> I'm going to go through and make a few assignments there, so that the page sorts by person better
[07:04] <cjwatson> (even for cases where it's obvious due to package)
[07:04]  * calc wishes the list had source packages listed
[07:05] <TheMuso> calc: Same here. Filtering out fix released bugs would also be nice.
[07:05] <calc> TheMuso: yea
[07:05] <cjwatson> asac: there are a lot of firefox bugs on that list; are you on top of them?
[07:07] <slangasek> it does seem that people are using the milestone for "everything I'm planning to work on between now and the release", rather than "bugs that are critical to resolve for 8.04" - indeed, I've even seen people make comments in the bugs to this effect when setting the milestone :)  Don't forget that we also have https://bugs.launchpad.net/ubuntu/hardy/+bugs as a pool of release-nominated bugs, it would be helpful if bugs that are targets
[07:07] <asac> cjwatson: i use milestones to keep everything on radar that would be nice to still fix. most important ones should be done already or fix committed though
[07:08] <calc> slangasek: i just moved all of my bugs up to critical instead of milestoning them since i knew that might give you a heart attack ;-)
[07:09] <slangasek> asac: can "would be nice" bugs be moved to release nominations + assigned to you?  that leaves them somewhere trackable, while helping to make it clear which bugs are to be considered blockers
[07:09] <calc> by the way as far as release-nominated bugs go, is there a way to see all bugs release-nominated or not?
[07:09] <calc> eg if a bug is nominated for eg dapper but closed in hardy it doesn't appear in the current bug list
[07:09] <slangasek> https://bugs.launchpad.net/ubuntu/$release/+nominations
[07:10] <asac> slangasek: i am lame in using launchpad. i will go through the list and move things that are unlikely to get fixed in time to .1
[07:10] <asac> is that ok?
[07:10] <calc> slangasek: i meant more of is there a way to see all bugs open on a particular package regardless of where they are open
[07:12] <asac> slangasek: in general everything that is importance "high" or more is a blocker i'd consider bad to push forward - if that info helps you
[07:13] <slangasek> asac: please use release nominations instead of the milestones for bugs that are not obviously blockers for that milestone; it's more practical for release management purposes to escalate bugs from the pool of release-targetted bugs than to work out whether a given bug that's been targetted is a blocker for a non-obvious reason
[07:13] <slangasek> asac: do you know about https://bugs.launchpad.net/~asac/+assignedbugs, btw?
[07:14] <slangasek> calc: I don't know of anything along those lines, sorry
[07:14] <calc> slangasek: ok
[07:17] <cjwatson> so the milestone list is a bit of a wash (I should have had a look before the meeting and done assignments!), but please also have a look at https://bugs.launchpad.net/ubuntu/hardy/+bugs, which is a bit more digestible
[07:18] <cjwatson> asac: bug 162609: as far as hardy's concerned, does that just need ubufox's dependency on apturl to be made versioned?
[07:18] <ubotu> Launchpad bug 162609 in ubufox "plugin finder wizard and apturl don't use the same http proxy" [High,Confirmed] https://launchpad.net/bugs/162609
[07:20] <asac> cjwatson: i think thats already fixed
[07:20] <asac> cjwatson: ill check that
[07:20] <cjwatson> evand: there are still quite a few ubiquity bugs in /ubuntu/hardy/+bugs; do we need to draft in some help?
[07:20] <cjwatson> asac: the dependency isn't versioned in the current archive (I checked first)
[07:21] <evand> hrm
[07:24] <evand> If we have the help available, it's welcome.  I think I can handle the major bugs though (tzmap remaining issues, miscalculation on size check, neverending ok button when resizing, preseeding keymap not working in ubiquity)
[07:24] <cjwatson> ArneGoetje: I noticed a couple of scim bugs on /ubuntu/hardy/+bugs. Do we dodge bug 66104 by using scim-bridge? Is any help needed on bug 199592?
[07:24] <ubotu> Launchpad bug 66104 in scim "[Gutsy] scim: input freezes in various applications under XIM mode" [Medium,In progress] https://launchpad.net/bugs/66104
[07:24] <ubotu> Launchpad bug 199592 in scim-bridge "scim-bridge crashed with SIGSEGV in scim::Module::unload()" [Medium,In progress] https://launchpad.net/bugs/199592
[07:25] <doko> I uploaded a XIM fix yesterday (but apparently this was for something seen for the java awt bindings)
[07:25] <evand> and I think we're quite close on the accessibility issues with ubiquity
[07:25] <ArneGoetje> cjwatson: for 66104, yes, we dodge that with scim-bridge... although libX11 has been patched recently... still need to confirm if the bug is now really fixed or not.
[07:25] <bryce> looks like most of the remaining milestoned xorg bugs are just "bug clots", where someone posted a generic sounding symptom and everyone with any issue sounding vaguely similar piled on.  I've been keeping an eye on them for a while to see if useful info like backtraces or whatever come up, but guess not.  They are too chaotic to be milestoned really.  I'll take another look and probably ask people to file new bugs if their iss
[07:25] <bryce> ues still exist.
[07:26] <slangasek> bryce: in that case, should/could the bugs be un-milestoned?
[07:26] <TheMuso> evand: I am happy to start early tomorrow if it means we can squash the a11y issues more easily.
[07:26] <ArneGoetje> cjwatson: for 199592, I still need some help to find out what's going on. The crash happens only once after a new install and then never again...
[07:27] <evand> bryce: have you seen bug 194848 yet?
[07:27] <ubotu> Launchpad bug 194848 in xorg-server "hardy alpha 5 closes session after choose keyboard (dup-of: 184651)" [Undecided,Confirmed] https://launchpad.net/bugs/194848
[07:27] <ubotu> Launchpad bug 184651 in xorg-server "Crash when starting gnome-settings-daemon" [High,In progress] https://launchpad.net/bugs/184651
[07:27] <doko> the scim-bridge SIGSEGV still needs to be reproduced
[07:27] <ArneGoetje> cjwatson: and reportedly for a new user account... so maybe something is wrong with the ~/.scim directory or so...
[07:27] <bryce> slangasek: yup, or even just closed as fixed, if the original issue was seen to be fixed.
[07:27] <evand> TheMuso: ok, I'll work on that fix now.  Got caught up in other bugs.
[07:28] <bryce> evand: no I hadn't
[07:28] <bryce> oh wait, that's a dupe of 184651
[07:28] <TheMuso> evand: Ok whenever, but it still doesn't help solve the orca zombification issues...
[07:28] <evand> ah, I forgot about that :/
[07:29] <cjwatson> doko: could you help out with the segv? there's what appears to be a partial repro recipe in the bug
[07:29] <bryce> evand: ok hadn't seen that one either.  I can talk to timo about it; sounds like he already looked into it
[07:30] <slangasek> bryce: if they shouldn't actually be blockers, it's helpful to unmilestone them in the event that there's something in the bug description (or metadata in the forums...) that causes people to congregate around those bugs
[07:30] <evand> ok
[07:30] <cjwatson> bryce: 184651 definitely needs to be a blocker due to the installer impact
[07:30] <doko> cjwatson: yes
[07:30] <slangasek> otherwise they have a tendency to be reopened and show up on the milestone list :)
[07:30] <cjwatson> doko: thanks
[07:30] <bryce> evand: there were a couple gnome-settings-daemon crashes I'd been working on earlier, but this one looks unrelated (Xkb rather than Xrandr).  But I'll look into it.
[07:31] <bryce> slangasek: good idea
[07:31] <evand> much appreciated
[07:32] <cjwatson> ArneGoetje: have you seen bug 153521? (it's a rather confused bug, as Steve has pointed out ...)
[07:32] <ubotu> Launchpad bug 153521 in fontconfig "fonts are blurred with subpixel rendering" [High,Triaged] https://launchpad.net/bugs/153521
[07:32] <ArneGoetje> cjwatson: yes, I've seen that...
[07:33] <ArneGoetje> cjwatson: however, the fonts blurring is expected IMHO, because of subpixel redering being turned on... that's what it's all about, isn't it?
[07:33] <ogra_cmpc_> err
[07:34] <ogra_cmpc_> isnt that depending on your output ?
[07:34] <ogra_cmpc_> s/output/output device/
[07:34] <slangasek> ArneGoetje: unfortunately since I don't have a 150 dpi display, I've been unable to figure out whether it's an aesthetic question, or a real problem with the display
[07:34] <slangasek> s/display$/rendering/
[07:34] <slangasek> if the fonts are really being rendered as we want them to be, then "wontfix" may be appropriate anyway
[07:35] <ArneGoetje> slangasek: you will get that effect on any display with a lower dpi setting.
[07:35] <slangasek> ArneGoetje: what's "lower dpi" here?
[07:35] <ogra_cmpc_> as i learned it, subpixel rendering will look blurry on tubes but make LCDs more crisp
[07:35] <ArneGoetje> slangasek: our default setting is to turn that feature off. if the user want's it he can turn it on by himself.
[07:35] <slangasek> ArneGoetje: er, no?
[07:36] <slangasek> our default setting is that subpixel smoothing is on for LCDs, I thought?
[07:36] <ArneGoetje> slangasek: not on my machine... it uses greyscale by default
[07:36] <doko> hmm, these screenshots are neither gnomish or kdeish
[07:37] <ArneGoetje> slangasek: our default dpi setting is 96dpi as opposed to highend displays with >150dpi
[07:38] <slangasek> ok, confirmed with a blank account, subpixel rendering isn't on by default
[07:38] <slangasek> at least according to System -> Preferences -> Appearance -> fonts
[07:38] <ArneGoetje> slangasek: yes, that's what I mean.
[07:39] <slangasek> ArneGoetje: "our default dpi setting" - so this is still being overridden somewhere in the desktop, rather than using the real dpi value?
[07:39] <ArneGoetje> slangasek: and my recent fontconfig patch will enforce the same setting on the whole system by default.
[07:39] <slangasek> I mean, that would explain why someone with a 150 dpi display would consider all fonts <= 12pt to be "small"...
[07:39] <ogra_cmpc_> slangasek, xdpyinfo |grep dots
[07:40] <ArneGoetje> slangasek: System -> Preferences -> Appearance -> fonts
[07:40] <ogra_cmpc_> check yourself :)
[07:40] <bryce> slangasek: once someone has nominated a bug for a release, is there a way to un-nominate it?  I see that long long ago someone nominated bug 34590, but it's a wishlist for DRI on some ancient card that's probably never going to get solved.  It seems to have gotten stuck in "nomination hell" and keeps getting bumped forward releases.
[07:40] <ubotu> Launchpad bug 34590 in xserver-xorg-video-ati "DRI not Automatically Enabled for ATI Rage Mobility P/M - Mach64" [Wishlist,Confirmed] https://launchpad.net/bugs/34590
[07:40] <slangasek> ogra_cmpc_: er, that only tells me what the X server thinks, not what fontconfig et al. think
[07:40] <ogra_cmpc_> for me that reports an odd value iof 96x77 px
[07:40] <slangasek> bryce: there's a hackish way to un-target, yes; remind me about that after the meeting?
[07:40] <ogra_cmpc_> fontconfoig is supposed to use what X offers it i though
[07:40] <bryce> ok will do
[07:41] <cjwatson> slangasek: can you remind me of the rune for that? I encountered another bug that could do with untargetting last night
[07:42] <slangasek> cjwatson: it involves marking the bug as either 'invalid' or 'wontfix' (don't remember which) on the release task
[07:42] <cjwatson> ugh! does it then come back somewhere else?
[07:42] <ArneGoetje> I'm not how fontconfig is involved in the dpi game though...
[07:42] <slangasek> which then lets you track it again outside the release, yes :)
[07:42] <cjwatson> wow, you weren't kidding
[07:43] <bryce> aha, wontfix does it
[07:43] <Hobbsee> slangasek: that doesn't actually remove the nomination, does it?
[07:43] <cjwatson> ok, the last thing I wanted people to glance through was http://people.ubuntu.com/~ogasawara/qa-hardy-list-archive/sort-by-package/platform-buglist.html
[07:43] <cjwatson> this is a *lot* better than it was before I went on holiday
[07:43] <asac> i think i know why i tried to not use the confusing nomination feature ;)
[07:43] <cjwatson> if there's anything there that shouldn't be for hardy, please remove the 'qa-hardy-platform' tag from the bug (and explain why in a comment) and it'll go away
[07:44] <slangasek> asac: tsss :)
[07:45] <slangasek> Hobbsee: the nomination doesn't disappear entirely, but since it's "wontfix"ed it falls off any relevant lists
[07:45] <Hobbsee> ah right
[07:45] <slangasek> Hobbsee: while also letting you track it again outside the release stream
[07:45] <asac> (the flash crashers on that qa list are not in my hands btw)
[07:45] <Hobbsee> yup
[07:46] <cjwatson> asac: are they in anyone's hands?
[07:46] <ogra_cmpc_> adobes ?
[07:46] <cjwatson> ogra_cmpc_: gnash, dude
[07:46] <ogra_cmpc_> oops
[07:46]  * ogra_cmpc_ hides his sleepy head
[07:47] <cjwatson> oh, maybe not all gnash
[07:47] <cjwatson> there are some libflashplayer.so-related bugs, maybe that's what asac was referring to
[07:48] <asac> yeah sorry ... that comment was about adobe flash
[07:48] <slangasek> hmm, maybe one of those is the bug that's currently preventing me from watching April Fool's videos, perhaps I should look and claim it ;)
[07:49] <asac> slangasek: does it crash?
[07:49] <ogra_cmpc_> if the joke isnt that there is no video behind theselinks indeed :)
[07:49] <asac> lol
[07:50] <slangasek> asac: it doesn't even show up in about:plugins (64-bit w/ nspluginwrapper)
[07:50] <cjwatson> ok, sorry ogra
[07:50] <ogra_cmpc_> cjwatson, nm
[07:50] <cjwatson> ok, any other business beyond bug lists? I'm going to continue looking through those and assigning
[07:50] <asac> slangasek: *cough*
[07:51] <slangasek> other business - yes
[07:51] <slangasek> before everybody scatters, I'd like to highlight bug #210607
[07:51] <ubotu> Launchpad bug 210607 in tzdata "Sydney timezone is wrong when set by tzselect, right when set by $TZ (dup-of: 209429)" [Undecided,New] https://launchpad.net/bugs/210607
[07:51] <ubotu> Launchpad bug 209429 in tzdata "/etc/timezone does not exist" [Medium,Incomplete] https://launchpad.net/bugs/209429
[07:51] <calc> bug 209783 needs syncing asap also :)
[07:51] <ogra_cmpc_> erm, btw these flash bugs are a year old
[07:51] <ubotu> Launchpad bug 209783 in translate-toolkit "UVF exception / sync request for translate-toolkit" [Undecided,New] https://launchpad.net/bugs/209783
[07:51] <bryce> (bug 197673 is my top priority but have made good progress on it of late and hope to have it closed soonish)
[07:51] <ubotu> Launchpad bug 197673 in gnome-control-center "gnome-display-properties should revert change automatically if not acknowledged" [High,In progress] https://launchpad.net/bugs/197673
[07:52] <asac> slangasek: can you check if there is a libflashplayer-alternative.so setup in /usr/lib/xulrunner-addons/plugins?
[07:52] <slangasek> er, I mean bug #209429. it's been reasonably unmilestoned because it's not reproducible, but it's possible that this affects many more systems than are currently reporting it because you only notice it when the rules for your TZ change
[07:52] <TheMuso> slangasek: I had no problem on my hardy systems over the weekend when us Sydneysiders were previously supposed to change...
[07:52] <slangasek> so currently Australia is complaining, but in a few months it'll be some other country, etc. - please check your own systems to verify whether you have an /etc/timezone file
[07:52] <TheMuso> I'll keep an eye out for this weekend however, when are are changing.
[07:53] <slangasek> and if you don't, please talk to me so that we can try to ferret out the common thread among the affected systems
[07:53]  * asac has /etc/timezone
[07:53] <doko> bryce: will there be change with the compiz blacklisting of ati cards?
[07:53] <james_w> me too
[07:53] <cjwatson> slangasek: (209783 is in your/release-team's court again, I think)
[07:53] <calc> i have one
[07:53] <bryce> doko, not sure; I'm looking at that one again now
[07:53]  * ogra_cmpc_ too ( on last night classmate image as well as on the installed one that did the DST change fine)
[07:53] <slangasek> cjwatson: correct, next on my todo list
[07:54] <cjwatson> ok
[07:54] <calc> of course i might have a timezone file because i was messing with it when gnome clock decided to go insane a while back
[07:54] <slangasek> asac: nope, no /usr/lib/xulrunner-addons/plugins/libflashplayer-alternative.so - so this is the bug, I guess? :)
[07:54] <bryce> doko, looks like there is a patch; it's up to the compiz folks but I'd guess this to be a high priority for hardy
[07:55] <slangasek> calc: right... :)
[07:55] <calc> slangasek: has anyone verified if this problem exists just on upgrades, etc?
[07:55] <bryce> doko, aha, the compiz folks have already committed it to bzr, so yeah looks like it's on the path to be included already
[07:55] <asac> slangasek: sorry, its flashplugin-alternative.so
[07:55] <calc> ah it looks like it is hard problem to track down
[07:56] <ogra_cmpc_> bryce, any idea about the status of the geode breakage ?
[07:56] <slangasek> calc: it's really not "verified" at all at this point, unfortunately - the users who are seeing the bug upgraded from a previous release, but we don't know yet what might have happened in between to cause the file to go missing
[07:56] <calc> oh btw i want to let everyone know about this: http://live.gnome.org/GnomeGoals/XDGConfigFolders ;-)
[07:56] <bryce> ogra_cmpc_: wha?  geode is broke too?
[07:56] <calc> slangasek: ah ok
[07:56]  * slangasek runs far away from XDGConfigFolders
[07:56] <ogra_cmpc_> bryce, well, the general amd driver breakage
[07:56] <bryce> ogra_cmpc_: no, we just did a new upload for them (still called -ati) the other week, I hadn't heard anything of problems
[07:56] <ogra_cmpc_> ati ?
[07:56] <bryce> ogra_cmpc_: they plan for another release soon.
[07:57] <bryce> er, -amd, sorry
[07:57]  * cjwatson joins slangasek in running away; I think that's a horrible meme we shouldn't assist
[07:57] <calc> basedir FTW! >:-)
[07:57] <ogra_cmpc_> ah :)
[07:57] <bryce> ETOOMANYDRIVERS
[07:57] <ogra_cmpc_> bryce, great, i just noticed that debian refused to add the fixes needed in xserver-xorg
[07:57] <cjwatson> (upstreams can do what they like, but distros moving stuff like that around is bad mojo)
[07:57] <calc> the main problem (i think?) is migrating prefs/data
[07:57] <slangasek> asac: oh, haha, I have that file, which points at the alternative, which points to gnash which isn't installed :)
[07:57] <bryce> the -amd -> -geode rename is going to save me so many typos ;-)
[07:57] <asac> slangasek: hmm
[07:57] <slangasek> asac: so that may be a gnash bug for failing to clear the alternative?
[07:57] <ogra_cmpc_> heh :)
[07:58] <calc> cjwatson: yea we shouldn't move it ourselves that would be a large amount of work for little gain
[07:58] <asac> slangasek: yes. though i think we --remove-all when no alternative is left
[07:58] <cjwatson> I think GNOME are wasting their time too, but hey ;-)
[07:58] <cjwatson> .cache is a decent enough idea, but not the rest IMAO
[07:58] <slangasek> asac: but there is an alternative left, I have flashplugin-nonfree installed
[07:58] <slangasek> asac: but the symlink is pointing wrong
[07:58] <asac> slangasek: is that alternative set to manual mode?
[07:59] <slangasek> asac: yes
[07:59] <asac> slangasek: how old is your install?
[07:59] <slangasek> asac: I don't /think/ it was set by me...
[07:59] <slangasek> asac: originated as gutsy prerelease
[08:00] <asac> slangasek: if you --remove the last alternative the alternative ends up in manual mode (no idea if that is a bug)
[08:00] <slangasek> erm
[08:00] <asac> i think really old packages didn't do --remove-all in that case
[08:00] <asac> but gnash does it from what i can see ... lets llok at flashplugin-nonfree
[08:00] <slangasek> I don't think packages are *supposed* to do --remove-all
[08:00] <slangasek> this is not a bug I've ever heard of before in u-a
[08:01] <slangasek> and doesn't match the documentation of --remove in the manpage
[08:01] <slangasek> anyway, my flash curiosities needn't be fodder for #u-meeting
[08:01] <cjwatson> I was about to say, we're at time and I need more coffee. :)
[08:02] <asac> slangasek: ;)
[08:02] <cjwatson> looks like other business has mostly dried up, anything else -> #ubuntu-devel; thanks all, adjourned
[08:02] <ogra_cmpc_> thanks
[08:02] <evand> thanks
[08:02] <ArneGoetje> thanks
[08:02] <asac> thank you!
[08:02] <bryce> cjwatson: for next meeting's agenda can you talk about post-release LTS support tasks?
[08:02] <bryce> thanks
[08:02] <cjwatson> bryce: good idea
[08:02] <james_w> thank you
[08:02] <TheMuso> thanks
[08:02] <calc> goodnight
[08:03] <slangasek> thanks :)
[08:07] <tjaalton> ogra_cmpc_: the patches that are needed for -amd are already in ubuntu, and debian has added them yesterday
[08:07] <ogra_cmpc_> oh, great
[08:07] <ogra_cmpc_> i had heard the debian maintainer didnt want to apply them at all
[08:08] <ogra_cmpc_> good that he changed his mind
[08:09] <tjaalton> he wanted to wait until it was merged upstream
[08:09] <ogra_cmpc_> ah
[08:10] <tjaalton> and now that most of the blockers for xserver 1.4 are fixed it, it can enter testing
[08:10] <tjaalton> and not wait for 1.5
[08:10] <ogra_cmpc_> right
[08:10] <ogra_cmpc_> given that debian still has half a year or so for the proposed release i found that attitude a bit silly, but well ...
[08:11] <tjaalton> heh
[08:11] <tjaalton> well, q-funk didn't actually help there..
[08:11] <slangasek> patches applied to which package?
[08:11] <ogra_cmpc_> xserver-xorg
[08:12] <tjaalton> kept pushing all the time and the maintainers got provoked
[08:12] <ogra_cmpc_> a set of three patches was needed to make the amd driver work at all
[08:12] <slangasek> ah, ok
[08:12] <tjaalton> slangasek: yes, those have been in for some time now
[08:12] <ogra_cmpc_> he accepted one of the three (which didnt help at all)
[08:13] <slangasek> fwiw, I was confused by the references to "the debian maintainer", since xserver-xorg is team-maintained in Debian :)
[08:13] <tjaalton> slangasek: also, I'd like to merge xorg-server with debian when the current version is released, since they've pulled stuff from the upstream 1.4-branch and us, so we could drop 10+ patches from our branch
[08:13] <ogra_cmpc_> but yeah, q-funk has massive interest in getting that wor,k, his company lives from selling thin clients that all use geode
[08:13] <slangasek> (... and telling me that they were provoked by q-funk also doesn't narrow it down much...)
[08:14] <ogra_cmpc_> he couldnt use gutsy because of that breakage
[08:14] <ogra_cmpc_> (or etch/lenny)
[08:14] <slangasek> tjaalton: you can merge it however you like for intrepid, but don't look at me for a freeze exception for what amounts to a rebase ;)
[08:15] <ogra_cmpc_> many people in the thin client world are angry with us (even its not our fault, its upstream breakage) because of that
[08:15] <tjaalton> slangasek: ok, so I'll just pull the upstream fixes then?
[08:15] <slangasek> tjaalton: yes, please
[08:15] <tjaalton> will do
[08:15] <ogra_cmpc_> we should probably not clutter the channel logs here btw and move over to -devel :)
[08:16] <tjaalton> heh yeah
[08:16] <tjaalton> if there's anything left :)
[08:17] <ogra_cmpc_> if geode works i'm as happy as i can be :)
[08:17] <tjaalton> I haven't seen q-funk complaining in weeks
[08:18] <tjaalton> *for
[19:01] <heno> hello
[19:01] <Iulian> Hey!
[19:01] <nand> hi
[19:04] <heno> #startmeeting
[19:04]  * ogasawara_ waves
[19:05] <pedro_> hi hi
[19:05] <heno> hm, no bot today?
[19:05] <heno> anyway, welcome all!
[19:06] <heno> jcastro: here?
[19:06] <davmor2> sorry I'm late :)
[19:06] <bdmurray> Hello!  Is it 1900?
[19:07] <pedro_> bdmurray: i'm wondering the same...
[19:07] <heno> arg!
[19:07] <pedro_> probably that's why evolution didn't tell me anything
[19:07] <davmor2> 19:07
[19:07] <heno> why didn't anyone stop me? :)
[19:07] <nand> oh yeah, we switched time
[19:08] <heno> davmor2: but not UTC
[19:08] <nand> now is 20 UTC, right?
[19:08] <davmor2> ah
[19:08]  * liw starts recruiting people to the Alliance Against DST
[19:08] <heno> the meeting page clearly says UTC (and I wrote it ...)
[19:08] <liw> so we already had the meeting an hour ago, right
[19:09] <heno> no, it's an hour from now
[19:09] <bdmurray> That's what I'd thought.
[19:09] <pedro_> it's 18 UTC now
[19:09] <heno> seeing that we're all here, shall we go ahead?
[19:10] <liw> I'm fine with now
[19:10] <ogasawara_> +1
[19:10] <pedro_> yeah go for it
[19:10] <heno> apologies to those who miss it and are reading this in logs ...
[19:11] <heno> [TOPIC] New team member introduction: Chris Gregan, Mobile QA
[19:11] <heno> everyone wave to cgregan!
[19:11] <cgregan> Hello team
[19:11] <liw> cgregan, hi
[19:11] <pedro_> welcome cgregan!
[19:11] <davmor2> I thought UTC was bst
[19:11] <ogasawara_> hi cregan!
[19:11] <Iulian> Hello cgregan
[19:11] <heno> Chris has been keeping busy getting up to speed with the mobile team
[19:12] <heno> He'll be doing bug management and testing on mobile
[19:12] <davmor2> brave man well done :)
[19:12] <pedro_> rock on!
[19:13] <heno> cgregan: you can find QA team members in #ubuntu-bugs and #ubuntu-testing usually
[19:13] <cgregan> heno: good to know...I will add them to my, growing, list of irc channels
[19:13] <heno> great
[19:13] <davmor2> cgregan: it only gets bigger :)
[19:14] <heno> I don't see jcastro here just yet, so let's take topic #3 for now
[19:14] <heno> [TOPIC] Test plan review for RC/Final
[19:15] <heno> davmor2: has been updating the Xubuntu and KDE4 plans with nice graphics :)
[19:15] <davmor2> I got a boat load to upload to the kde4 one once that is out of the way I'll start up-dating the others now we have nice layout :)
[19:15] <heno> I'd like everyone to look over the test plans if you have a chance and fix obvious errors and out-of-dateness
[19:16] <heno> davmor2: rock!
[19:16] <cgregan> davmor2: Can you send link to plans?
[19:16] <liw> cgregan, https://wiki.ubuntu.com/Testing/Cases is that what you mean?
[19:16] <cgregan> liw: perfect
[19:17] <cgregan> thanks
[19:17] <heno> cgregan comes from a backgound in mostly proprietary software QA
[19:17] <davmor2> https://wiki.ubuntu.com/Testing/Cases/XubuntuDesktop is likely to be the general layout making it easy to see what the desktop should look like and the apps we're describing also.
[19:17] <heno> cgregan: I'd appreciate your take on these plans
[19:18] <cgregan> heno: sure...I'll review and update the team
[19:18] <liw> davmor2, awesome work
[19:19] <davmor2> liw: the kde4 was the other layout but we agreed it was easier with images :)
[19:19] <davmor2> kde4 is mostly text layout hightlighting things that are important
[19:19] <davmor2> to many t's in highlighting :)
[19:20] <heno> I think jcastro may have fallen victim to my scheduling gaffe :(
[19:21] <bdmurray> Should have a test case for ubiquity-only?
[19:21] <heno> let's cover the upstream bug topic now and I can have a phone call with him later
[19:22] <heno> bdmurray: is it very different from Live -> ubiquity?
[19:22] <heno> We should make sure both paths get tested indeed
[19:22] <bdmurray> Only in terms of accessing it.
[19:22] <davmor2> bdmurray: you can't really do that with ease because there are several versions of ubiquity each slightly different
[19:22] <heno> and it's important to exercise both code paths
[19:24] <heno> davmor2: but on a given CD is there much difference in running ubiquity with 'Install only' and Live -> Install?
[19:24] <bdmurray> The installation process does not change but the amount of memory required for ubiquity only is much less.
[19:25] <heno> I'm hesitant about adding a test case for every variation because we quickly get too many
[19:25] <liw> heno, I was thinking the same thing
[19:25] <heno> though this may be a valid case
[19:26] <davmor2> heno: with you no I don't believe so only the differences that are there anyway.  that is that, Xubuntu pulls in the language packs, Kubuntu's is different in the way the map works  etc
[19:26] <bdmurray> Perhaps checking with cjwatson or evand would be best then.
[19:26] <heno> a stop-gat might be to ask people to add a tracker comment about which path they used
[19:27] <heno> we generally have a fair number of people testing desktop i386 images at least - we should just make sure people use different methods
[19:28]  * heno makes a note for subscription tracking
[19:28] <davmor2> heno: I think it would be more prudent to stick ubiquity in it's own section at the top of each live cd case listing the fact that it can be accessed via the menu directly and any differences in the versions
[19:29] <davmor2> that covers every aspect then
[19:30] <heno> yep, people usually have 3 or so partitioning methods assigned on a given CD and should spread that over start paths
[19:30] <heno> davmor2: can you add that?
[19:30] <heno> bdmurray: thanks for pointing that out
[19:31] <heno> [TOPIC] Upstreaming bugs; wiki guides and bugdays
[19:31] <davmor2> I'll add it to the list :)  I can throw together some SS of it in action and then upload those as well it shouldn't be too hard.
[19:31] <heno> I understand there were some mixed views of the value of the upstream linking yesterday
[19:32] <bdmurray> By the way https://wiki.ubuntu.com/Testing/Cases/Wubi isn't linked to on the main page.
[19:32] <heno> bdmurray: it is at the bottom ;)
[19:32] <heno> I want to refresh that landing page actually
[19:32] <heno> it's not very inviting
[19:32] <bdmurray> Oh, I was just looking at the top section.
[19:33] <heno> It should be added, you are right
[19:33]  * heno takes an action to tidy that page up
[19:33] <bdmurray> heno: Do you know what the negative opinions are? I haven't heard them.
[19:33] <davmor2> bdmurray: it's on the list we will probably lose winfoss
[19:34] <bdmurray> davmor2: cool, thanks!
[19:34] <pedro_> bdmurray: basically seb128 and i were talking that the bugday caused us more noise than anything
[19:34] <pedro_> and it'd be nice if it happens during another time of the release process
[19:35] <heno> I think the problem is that the upstreaming on gnome bugs was already quite good
[19:35] <bdmurray> noise in what sense? more bugmail or something else?
[19:35] <pedro_> yeah lot of bugmail
[19:35] <heno> and it's difficult to improve on that for people with less experience
[19:35] <pedro_> we already have a lot daily ;-)
[19:36] <heno> I think some of the added links may not have been correct
[19:37] <pedro_> yeah and then we have to correct them
[19:37] <bdmurray> Okay, both of those points make sense to me.  Are the bug watches useful though?
[19:37] <bdmurray> Or rather bug watches in general useful?
[19:37] <heno> I'm also wondering if picking this low hanging fruit isn't really just sidestepping the issue
[19:38] <heno> filing bugs upstream well is hard and requires insight into that upstream's bug landscape and culture
[19:39] <heno> we should probably rather focus on packages with very few bugs filed/linked upstream
[19:39] <heno> start fling/linking those and gaining the experience and connections
[19:39] <bdmurray> I think there are 2 separate issues though. 1) filing bugs upstream and 2) linking bugs upstream.
[19:40] <heno> bdmurray: you mean link bugs that someone else has already marked as an upstream issue?
[19:41] <bdmurray> for point 2 I mean adding a bug watch for an existing upstream bug report
[19:41] <heno> IMO when you look at a bug with a view to link it upstream you first search the upstream tracker and link if it's found and file if not
[19:41] <bdmurray> While it still requires a fair bit of knowledge - it can require less than actually filing it upstream.
[19:42] <heno> but both should be part of the same workflow right?
[19:42] <heno> the difficult of filing upstream depends a bit on the cost of doing a bad job at it
[19:43] <heno> IOW - how upset does upstream get if you file a poor bug or dupe?
[19:43] <bdmurray> You said "filing bugs upstream well is hard".  I'm just saying that linking is different than filing and isn't as hard.
[19:44] <bdmurray> So while they are part of the same workflow they have different degrees of difficulty.
[19:44] <heno> If they are helpful in correcting you and helping you learn, then nothing is lost by trying, but if it pisses them off it's more tricky
[19:44] <heno> this will depend on the upstream and our approach
[19:46] <heno> bdmurray: I mostly agree. but how many of the linkable bugs are there? is it worth focusing on as an approach
[19:46] <heno> ?
[19:47] <heno> the number with links in the comments is one thing; the number that already exist upstream but nobody has pointed out is likely much larger
[19:48] <heno> bdmurray: do you think we should do more 'upstreaming' bug days, or should we make it a component of bug days generally?
[19:48] <bdmurray> heno: I'm still looking at the numbers as to how many linkable bugs there are.
[19:49] <heno> btw, has everyone seen https://bugs.launchpad.net/ubuntu/+upstreamreport ?
[19:49] <bdmurray> I agree with pedro than now isn't really the right time in the development cycle.  It'd be best done after Hardy releases.
[19:49] <heno> a view of how many bugs are filed/linked upstream by package
[19:50] <heno> bdmurray: I agree, that's a good point
[19:51] <heno> perhaps we should do some themes one looking for severe release blocking bugs and escalating those?
[19:51] <bdmurray> I think identifying and documenting how to find the right upstream bug is best and then adding that as a component to bug days makes sense.
[19:51] <heno> it would be good to get more eyes on the fresh bugs leading up to release
[19:52] <heno> ok, cool
[19:52] <heno> for now though - perhaps we can do a day looking at iso-testing bugs?
[19:52] <bdmurray> In regards to bug days I think revisiting bugs w/o a package would be a good idea as there may be something critical hiding there.
[19:52] <heno> yep
[19:52] <bdmurray> That too would be good.
[19:53] <heno> sounds like a plan
[19:53] <heno> any other topic today?
[19:53] <bdmurray> One thing
[19:54] <bdmurray> Or 2 maybe
[19:54] <jcastro> hi guys
[19:54] <jcastro> sorry I am late, personal emergency
[19:54] <davmor2> no but I would like to say that I'll add the ubiquity images to https://wiki.ubuntu.com/Testing/Cases/LiveCDInstall as it seems the most sensible place for it :)
[19:54] <bdmurray> I've started a list of triaging specialities at https://wiki.ubuntu.com/BugSquad/Contacts - please add yourself i you aren't already there.
[19:54] <heno> jcastro: actually, we are early ...
[19:55] <heno> jcastro: I'll phone you in a few minutes and catch you up
[19:55] <jcastro> ok
[19:56] <heno> Packages/Area of Specialty - bdmurrary - Everything :)
[19:56] <bdmurray> geez! I didn't even write that.
[19:56] <davmor2> heno: one thing also what is happening about the LP testing team?
[19:57] <heno> the page looks good
[19:58] <heno> ok, I think we're done
[19:58] <heno> thanks everyone!
[19:58] <cgregan> heno: is this the regular time each week?
[19:58] <liw> cgregan, https://wiki.ubuntu.com/QATeam/Meetings has the times
[19:58] <pedro_> cgregan: the schedule is at wiki.ubuntu.com/QATeam/Meetings
[19:58] <pedro_> jeje
[19:58] <heno> cgregan: except we started an hour early by mistake this week ...
[19:59] <heno> my mistake for the record
[19:59] <cgregan> liw,pedro_, hino: thanks
[19:59] <pedro_> you're welcome
[19:59] <heno> indeed
[20:00] <heno> google calendar is not helping though
[20:00] <heno> #endmeeting
[20:00] <jcastro> DST wrecks more ubuntu productivity!
[20:00] <heno> (yeah I know there is not bot, but it's reflex now)
[20:01] <stgraber_> heno: oh, I wondered why you were finishing the meeting :) So my schedule was right
[20:01] <davmor2> stgraber_ indeed I thought I was late till I got here an hour early :)
[20:03] <heno> we made very good time today though, finished just before start
[20:04] <stgraber_> heno: anything important I missed ?
[20:04] <liw> stgraber, I can e-mail you the channel log for the meeting, ifyou give me an e-mail address
[20:05] <stgraber_> liw: stgraber@ubuntu.com
[20:05] <heno> stgraber_: we looked at the test cases a bit
[20:05] <heno> we will all look them over for up-to-dateness before RC
[20:06] <stgraber_> heno: yes, I saw quite a lot of update on the wiki. I'll update the LTSP and Edubuntu ones soon
[20:06] <liw> stgraber, sent
[20:06] <stgraber_> liw: thanks
[20:20] <nxvl> @now
[20:20] <nxvl> @schedule
[20:20] <nxvl> ubotu: ping
[20:21] <ubotu> Current time in Etc/UTC: April 02 2008, 19:20:27 - Next meeting: Server Team in 1 hour 39 minutes
[20:21] <ubotu> Schedule for Etc/UTC: 02 Apr 21:00: Server Team | 09 Apr 21:00: Server Team | 16 Apr 21:00: Server Team | 23 Apr 21:00: Server Team | 30 Apr 21:00: Server Team
[20:21] <nxvl> @schedule Lima
[20:21] <ubotu> ping yourself ;-) really the diodes all down my left side are sore
[20:21] <ubotu> Schedule for America/Lima: 02 Apr 16:00: Server Team | 09 Apr 16:00: Server Team | 16 Apr 16:00: Server Team | 23 Apr 16:00: Server Team | 30 Apr 16:00: Server Team
[20:30] <Rinchen> ==> we're having some issues with the Fridge's event calendar which feeds this channel. Not all meetings may show up until it's fixed.
[20:37] <zul> @schedule montreal
[20:37] <ubotu> Schedule for America/Montreal: 02 Apr 17:00: Server Team | 09 Apr 17:00: Server Team | 16 Apr 17:00: Server Team | 23 Apr 17:00: Server Team | 30 Apr 17:00: Server Team
[21:54] <zul> *cough*
[21:55] <kirkland> *sneeze*
[21:55] <nealmcb> *ahhhh*
[21:57] <nijaba> aaatchaa
[21:57] <sommer> hey all
[21:57] <nealmcb> sommer: sounds like hay fever....
[21:57]  * mathiaz waves and smiles :)
[21:57] <zul> no its my coooold
[21:58] <sommer> heh, I feel fine
[21:59] <ajmitch> ah, it's that time of the week
[21:59] <zul> hey ajmitch
[21:59] <zul> i thought groundhog day was last week ;)
[22:00]  * jdstrand waves
[22:01] <soren> o/
[22:01] <kirkland> [o]
[22:01] <soren> kirkland: That's a new one :)
[22:01] <kirkland> soren: muscles!
[22:02] <mathiaz> all - right - let's get started
[22:02] <soren> Oh, I thought it was a robotic kind of thing.
[22:02] <owh> Waking up at 5am for a meeting - blah.
[22:02] <mathiaz> #startmeeting
[22:02] <zul> yarr
[22:03] <soren> No mootbot?
[22:03] <owh> Nope
[22:03] <mathiaz> hum... mootbot is still sleeping...
[22:03] <owh> I feel the same way :)
[22:03] <mathiaz> bon...
[22:03] <soren> Well have to live without it.
[22:03] <mathiaz> [TOPIC] #
[22:03] <mathiaz> Review ACTION points from previous meeting.
[22:03] <mathiaz> last week meeting logs: https://wiki.ubuntu.com/MeetingLogs/Server/20080326
[22:04] <mathiaz> owh: status action init script ?
[22:04] <owh> Crap.
[22:04] <owh> Yes. No action done. I'll wake up some and action it today.
[22:05] <mathiaz> owh: great.
[22:05] <owh> My intent is to add the init.d scripts to the existing bug and add that to the debian list.
[22:05] <kirkland> mathiaz: I have something to add....
[22:05] <owh> Only so others can have the benefit of them.
[22:06] <owh> Bring it on.
[22:06] <kirkland> mathiaz: I'm attending the Linux Summit in Austin, TX next week, and there's a track on LSB (Linux Standards Base) which is the ISO standard that describes the init scripts (among many other things)
[22:06] <kirkland> mathiaz: I'll take some notes, and I'd like to use some of that to seed a discussion for what we can do for Ubuntu Server in that space, potentially as a UDS Prague topic
[22:07] <mathiaz> kirkland: great
[22:07] <owh> The more I hear about the future of the init scripts, the more I wonder if there is any point in pursuing our current solution.
[22:07] <kirkland> mathiaz: i'll report back here either next week, or more probably the next with the highlights
[22:07] <nealmcb> but knowing what it means for lsb compliance is important - thanks kirkland
[22:07] <kirkland> owh: i definitely think there's value in pushing patches to debian
[22:07] <mathiaz> owh: well - the futur of init scripts in ubuntu is probably going to upstart integration
[22:08] <owh> Are there others that agree with kirkland?
[22:08] <mathiaz> owh: I'd say to push current patches, but not develop new ones
[22:09] <owh> Is it appropriate to vote on it?
[22:09] <owh> I mean, I've done the work, but continuing is going to create work for others.
[22:09] <mathiaz> owh: well - that's up to them to accept it or not
[22:10] <mathiaz> owh: the patches are there , just send them
[22:10] <owh> Will do.
[22:10] <mathiaz> owh: and the debian maintainers will decide what they wanna do with it
[22:10] <owh> Yup.
[22:10] <mathiaz> [TOPIC] Wiki pages from help.ubuntu.com
[22:11] <mathiaz> sommer: did you have a look at the samba wiki pages ?
[22:11] <sommer> yep, I've started updating a few, but haven't gotten that far
[22:11] <sommer> should have more time toward the end of the week though
[22:12] <sommer> also created a page to link the others by category
[22:12] <sommer> it's cruisen
[22:13] <mathiaz> sommer: great
[22:13] <mathiaz> [TOPIC] Review high priority bugs related to the Server Team.
[22:13] <mathiaz> I haven't had time to compile such a list
[22:13] <mathiaz> So anyone has seen of such show-stopper bugs ?
[22:14] <sommer> we could focus no the one brought up last week
[22:14] <sommer> the ldap boot issue
[22:14] <mathiaz> sommer: I think zul and kirkland are working on it
[22:14] <nijaba> Not a show stopper, but would be nice to see the MOTD bug fixed...
[22:14] <mathiaz> nijaba: I think slangasek is assigned to it
[22:14] <sommer> oh, that's cool then
[22:15] <kirkland> mathiaz: i am working on it
[22:15] <kirkland> mathiaz: i've not been able to precisely reproduce it yet
[22:15] <kirkland> but i am actively multitasking on a vm right now on it ;-)
[22:15] <nijaba> mathiaz: nope, ubuntu-server-team still is assigned to #159371
[22:16] <mathiaz> nijaba: right
[22:17] <soren> Do we assign bugs to the team?
[22:17] <mathiaz> soren: no - I don't think it's a good idea
[22:17] <soren> Me neither.
[22:17] <mathiaz> soren: individual assigment may be better
[22:17] <soren> YEah. Otherwise -- somewhat ironically -- noone will do it.
[22:18] <nijaba> volunteer?
[22:18] <owh> soren: I suppose subscribing a bug to the team makes us aware of it, but to actually fix it needs an individual.
[22:18] <soren> owh: Right. That's what almost every other teams does.
[22:18] <nealmcb> team effort - I'll do the first byte - a "#" !
[22:19] <nealmcb> who's next?
[22:19] <soren> IIRC the kernel team does it differently.
[22:19] <mathiaz> nijaba: I'll make the upload
[22:19] <nijaba> nealmcb: the debdiff is already there
[22:19] <zul> soren: not really
[22:19] <soren> I'll bitch and moan about it.
[22:19]  * nijaba hugs mathiaz
[22:20] <mathiaz> apart from the ldap bug, anything else ?
[22:20] <mathiaz> I think the postgresql bug in the installer is fixed
[22:20] <zul> there are some weird apcahe sigsegv when upgrading from gutsy->hardy on amd64 but Im not sure why nor have the hardware
[22:21] <nijaba> there is a stupid bash_completion issue that kees and I stumbled upon
[22:21] <soren> bug no.?
[22:21] <mathiaz> nijaba: yes - I came across that one too
[22:21] <zul> soren: #210569
[22:21] <nijaba> bug #210013
[22:21] <ubotu> Launchpad bug 210013 in bash "bash-completion config replacement prompt on upgrade from gutsy to hardy" [Medium,Triaged] https://launchpad.net/bugs/210013
[22:23] <mathiaz> nijaba: right - it's a problem with the new bash package and handling in ucf
[22:23] <mathiaz> nijaba: we have the same issue with samba
[22:24] <mathiaz> allright - that's all for high-priority bugs
[22:25] <nijaba> also, there is a potential issue with iscsi (see last comment of Bug #192080) not sure soren has seen it.
[22:25] <ubotu> Launchpad bug 192080 in open-iscsi "shutdown fails.. nfs" [Undecided,Incomplete] https://launchpad.net/bugs/192080
[22:25] <mathiaz> I'll try to compile a list with the bugs
[22:25] <mathiaz> Or at least come up with a way to track them
[22:25] <nealmcb> is there a report on bugs with lots of duplicates?
[22:25] <soren> nijaba: Yeah, I've seen it.
[22:25] <mathiaz> zul: did you go through some of the bug and milestone them ?
[22:26] <nijaba> soren: good :)  I feel better now ;)
[22:26] <mathiaz> nealmcb: not really - the qa team is marking these
[22:26] <zul> mathiaz: I did some but I have to continue
[22:26] <mathiaz> zul: great - marking bug for the next hardy milestone seems like the way to proceed to keep track of important profile
[22:27] <mathiaz> s/profile/bug/
[22:28] <zul> ill move it up my todo list
[22:28] <mathiaz> talking about bug triagging, I'd like to mention an email sent by brian murray a few minutes ago
[22:28] <mathiaz> https://wiki.ubuntu.com/BugSquad/Contacts
[22:29] <mathiaz> I think we should put one of us as a contact for server related software
[22:29] <owh> mathiaz: What about just the bug list email address?
[22:30] <nijaba> mathiaz: do we need a dev for this?
[22:30] <owh> That would mean more eyeballs.
[22:30] <mathiaz> owh: which one do you refer to ? ubuntu-server or ubuntu-server-bugs ?
[22:30] <mathiaz> nijaba: no necessarly
[22:30] <owh> The latter mathiaz
[22:31] <mathiaz> brian mentionned in his email:Our thought was it
[22:31] <mathiaz> would be a useful guide of who talk to if you need help debugging a
[22:31] <mathiaz> particular package or part of Ubuntu.
[22:31] <owh> mathiaz: It means that those who are subscribed - arguably already in the bug business - see a request.
[22:31] <mathiaz> owh: it's more about contacting someone in person
[22:32] <owh> mathiaz: But I suspect that it will attract specific support requests from individuals, rather than triagers.
[22:32] <nijaba> mathiaz: if nobody wants to do it /me raises his hand
[22:32] <zul> mathiaz: so like a receptionist?
[22:33] <mathiaz> owh: well - I don't know what would be the outcome
[22:33] <nijaba> zul: right...
[22:33] <zul> for the lack of a better term
[22:33] <mathiaz> zul: probably - I don't exactly what brian is up to with this list
[22:33] <owh> mathiaz: I figure that the ubuntu-server-bugs is monitored 24/7, individuals sleep.
[22:33] <soren> They do?
[22:33] <soren> Slackers.
[22:33] <soren> :)
[22:34]  * nijaba now knows that soren *never* sleeps
[22:34] <owh> mathiaz: At the moment that address only gets automatic mail, so requests will stick out.
[22:34] <mathiaz> But I think we should have a row that says "Server related software" talk to ...
[22:34] <owh> soren: We're not talking about you :-)
[22:34] <soren> Ah :)
[22:34] <mathiaz> owh: yes - u-s-b is only set to receive bugs from LP
[22:34] <owh> mathiaz: Talk to the ubuntu-server team.
[22:34] <zul> soren: go back to sleep ;)
[22:34] <nealmcb> we could refer them to #ubuntu-server
[22:35] <owh> Yes, the would also work.
[22:35] <kirkland> mathiaz: hmm, using a list would change the model from the way it's currently used in https://wiki.ubuntu.com/BugSquad/Contacts
[22:35] <soren> zul: I don't sleep. I idle or wait or something.
[22:35] <owh> nealmcb: Our coverage is a little spotty though.
[22:35] <mathiaz> kirkland: right
[22:35] <kirkland> mathiaz: i'm not disagreeing, just pointing it out
[22:35] <mathiaz> owh: it seems that it's more about individuals
[22:35] <mathiaz> owh: this is not for a 24/7 support line
[22:35] <nijaba> as we said before: distributed responsability = no responsability
[22:36] <nealmcb> owh: true, but less spotty than an individual irc nick
[22:36] <zul> I guess if its too much for one person then nijaba and I could do it
[22:36] <owh> nijaba: The flip side of that is that one individual gets overwhelmed.
[22:36] <owh> nealmcb: Yes.
[22:36] <nijaba> owh: we'll talk about it when it happens
[22:36] <mathiaz> zul: well - I don't know if it really takes a lot of time
[22:36] <owh> Is there a way to identify U-S team members in #U-S?
[22:36] <zul> more coverage if people do it
[22:36] <zul> er...two people do it
[22:37] <mathiaz> I think someone should talk to bdmurray to know what he is up to
[22:37] <owh> +1
[22:37] <mathiaz> zul: I'm not sure that coverage is to point of this
[22:37] <nijaba> mathiaz: you can action me on that point
[22:38] <mathiaz> [ACTION] nijaba to talk to bdmurray to figure out what the BugSquad/Contacts wiki page is about
[22:40] <mathiaz> Well - that's all I have for now
[22:40] <mathiaz> [TOPIC] Any other Business
[22:40] <mathiaz> somebody wants to add something ?
[22:40] <owh> What happened to the iscsi testing stuff?
[22:41] <mathiaz> https://wiki.ubuntu.com/ServerTeam/ReportingPage
[22:41] <mathiaz> ^^ has a section about it
[22:41] <nijaba> limesurvey: Kees found a few sec issue on it. so we'll be waiting for them to be fixed before being able to host it somewhere
[22:41]  * kirkland waves
[22:43] <kirkland> umm, is the meeting still happening?
[22:43] <soren> I don't see it.
[22:43] <soren> :)
[22:43] <mathiaz> yes
[22:43] <sommer> I'm still meeting, heh
[22:43] <soren> Heh :)
[22:43] <mathiaz> just wondering if someone wants to add  something
[22:43]  * nealmcb cheers
[22:44] <owh> One moment I'm in a room with 117 people, then 113 of them run away :)
[22:44] <soren> nealmcb: Wow, you guys missed the coolest part of the meeting. It as awesome!
[22:44] <owh> soren: Was it the bit where you woke up?
[22:44] <nealmcb> you all finished up with the ibex?
[22:44] <soren> owh: iz sekrit.
[22:44] <ajmitch> no, the bit where soren promised to fix all outstanding bugs
[22:44] <owh> nealmcb: Release is next week :)
[22:45] <zul> you missed it bug #1 was fixed and there was much celebration
[22:45] <ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1
[22:45] <ajmitch> zul: thanks to jdong...
[22:45] <soren> owh: Not funny.
[22:45] <soren> :)
[22:45]  * owh is sleep deprived. The alarm didn't go off as expected :(
[22:46] <mathiaz> so - seems that none has anything else to add
[22:46] <mathiaz> [TOPIC] #
[22:46] <mathiaz> Agree on next meeting date and time.
[22:46] <mathiaz> next week, same time, same place ?
[22:46] <owh> mathiaz: That can't be right, a meeting that finishes early?
[22:46] <owh> mathiaz: WFM, Summer Time is over, now I'm UTC+8 :(
[22:46] <nijaba> that's because soren fixed all the bugs...
[22:46] <owh> :)
[22:48] <owh> Cool, that gives me 14 minutes to complete my action point for this meeting :)
[22:48] <dendrobates> bye.
[22:48] <mathiaz> ok - next meeting: next week, same time, same place
[22:48] <nealmcb> and soren fixed all the bugs because he wasn't interrupted on irc for 2 whole minutes!
[22:48] <mathiaz> thanks all for participating
[22:48] <mathiaz> and happy beta testing !
[22:48] <nijaba> thanks mathiaz
[22:48] <soren> nealmcb: Sounds like a dream :)
[22:48] <mathiaz> #endmeeting
[22:49] <owh> Thanks for hosting our get together again mathiaz
[22:49] <sommer> thanks mathiaz, later all
[22:49] <owh> Later