=== sflla1 is now known as sfllaw === sflla1 is now known as sfllaw === sflla1 is now known as sfllaw === sflla1 is now known as sfllaw === sflla1 is now known as sfllaw === sflla1 is now known as sfllaw === never|mobi is now known as neversfelde|mobi [06:48] hi [06:50] good morning [06:50] Greetings all. [06:51] * asac waves [06:51] hi [06:51] hi [06:53] heya [06:53] openoffice.org 2.4.0-3ubuntu1 is in hardy now :) [06:54] waiting on translate-toolkit to be sync'd [06:55] morning all [06:56] *yawn* [06:56] morning [06:57] good morning [07:00] * cjwatson counts on his fingers [07:00] I think that's everyone [07:00] so good morning everyone; hope you all had a good week while I was on holiday [07:01] morning :) [07:01] 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] 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] (I have a few items myself) [07:03] 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] yes; even discounting the bugs that are already fix-released [07:04] I'm going to go through and make a few assignments there, so that the page sorts by person better [07:04] (even for cases where it's obvious due to package) [07:04] * calc wishes the list had source packages listed [07:05] calc: Same here. Filtering out fix released bugs would also be nice. [07:05] TheMuso: yea [07:05] asac: there are a lot of firefox bugs on that list; are you on top of them? [07:07] 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] 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] 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] 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] by the way as far as release-nominated bugs go, is there a way to see all bugs release-nominated or not? [07:09] eg if a bug is nominated for eg dapper but closed in hardy it doesn't appear in the current bug list [07:09] https://bugs.launchpad.net/ubuntu/$release/+nominations [07:10] 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] is that ok? [07:10] 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] 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] 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] asac: do you know about https://bugs.launchpad.net/~asac/+assignedbugs, btw? [07:14] calc: I don't know of anything along those lines, sorry [07:14] slangasek: ok [07:17] 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] asac: bug 162609: as far as hardy's concerned, does that just need ubufox's dependency on apturl to be made versioned? [07:18] 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] cjwatson: i think thats already fixed [07:20] cjwatson: ill check that [07:20] evand: there are still quite a few ubiquity bugs in /ubuntu/hardy/+bugs; do we need to draft in some help? [07:20] asac: the dependency isn't versioned in the current archive (I checked first) [07:21] hrm [07:24] 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] 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] 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] 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] I uploaded a XIM fix yesterday (but apparently this was for something seen for the java awt bindings) [07:25] and I think we're quite close on the accessibility issues with ubiquity [07:25] 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] 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] ues still exist. [07:26] bryce: in that case, should/could the bugs be un-milestoned? [07:26] evand: I am happy to start early tomorrow if it means we can squash the a11y issues more easily. [07:26] 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] bryce: have you seen bug 194848 yet? [07:27] 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] Launchpad bug 184651 in xorg-server "Crash when starting gnome-settings-daemon" [High,In progress] https://launchpad.net/bugs/184651 [07:27] the scim-bridge SIGSEGV still needs to be reproduced [07:27] cjwatson: and reportedly for a new user account... so maybe something is wrong with the ~/.scim directory or so... [07:27] slangasek: yup, or even just closed as fixed, if the original issue was seen to be fixed. [07:27] TheMuso: ok, I'll work on that fix now. Got caught up in other bugs. [07:28] evand: no I hadn't [07:28] oh wait, that's a dupe of 184651 [07:28] evand: Ok whenever, but it still doesn't help solve the orca zombification issues... [07:28] ah, I forgot about that :/ [07:29] doko: could you help out with the segv? there's what appears to be a partial repro recipe in the bug [07:29] evand: ok hadn't seen that one either. I can talk to timo about it; sounds like he already looked into it [07:30] 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] ok [07:30] bryce: 184651 definitely needs to be a blocker due to the installer impact [07:30] cjwatson: yes [07:30] otherwise they have a tendency to be reopened and show up on the milestone list :) [07:30] doko: thanks [07:30] 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] slangasek: good idea [07:31] much appreciated [07:32] ArneGoetje: have you seen bug 153521? (it's a rather confused bug, as Steve has pointed out ...) [07:32] Launchpad bug 153521 in fontconfig "fonts are blurred with subpixel rendering" [High,Triaged] https://launchpad.net/bugs/153521 [07:32] cjwatson: yes, I've seen that... [07:33] 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] err [07:34] isnt that depending on your output ? [07:34] s/output/output device/ [07:34] 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] s/display$/rendering/ [07:34] if the fonts are really being rendered as we want them to be, then "wontfix" may be appropriate anyway [07:35] slangasek: you will get that effect on any display with a lower dpi setting. [07:35] ArneGoetje: what's "lower dpi" here? [07:35] as i learned it, subpixel rendering will look blurry on tubes but make LCDs more crisp [07:35] 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] ArneGoetje: er, no? [07:36] our default setting is that subpixel smoothing is on for LCDs, I thought? [07:36] slangasek: not on my machine... it uses greyscale by default [07:36] hmm, these screenshots are neither gnomish or kdeish [07:37] slangasek: our default dpi setting is 96dpi as opposed to highend displays with >150dpi [07:38] ok, confirmed with a blank account, subpixel rendering isn't on by default [07:38] at least according to System -> Preferences -> Appearance -> fonts [07:38] slangasek: yes, that's what I mean. [07:39] ArneGoetje: "our default dpi setting" - so this is still being overridden somewhere in the desktop, rather than using the real dpi value? [07:39] slangasek: and my recent fontconfig patch will enforce the same setting on the whole system by default. [07:39] I mean, that would explain why someone with a 150 dpi display would consider all fonts <= 12pt to be "small"... [07:39] slangasek, xdpyinfo |grep dots [07:40] slangasek: System -> Preferences -> Appearance -> fonts [07:40] check yourself :) [07:40] 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] 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] ogra_cmpc_: er, that only tells me what the X server thinks, not what fontconfig et al. think [07:40] for me that reports an odd value iof 96x77 px [07:40] bryce: there's a hackish way to un-target, yes; remind me about that after the meeting? [07:40] fontconfoig is supposed to use what X offers it i though [07:40] ok will do [07:41] slangasek: can you remind me of the rune for that? I encountered another bug that could do with untargetting last night [07:42] cjwatson: it involves marking the bug as either 'invalid' or 'wontfix' (don't remember which) on the release task [07:42] ugh! does it then come back somewhere else? [07:42] I'm not how fontconfig is involved in the dpi game though... [07:42] which then lets you track it again outside the release, yes :) [07:42] wow, you weren't kidding [07:43] aha, wontfix does it [07:43] slangasek: that doesn't actually remove the nomination, does it? [07:43] 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] this is a *lot* better than it was before I went on holiday [07:43] i think i know why i tried to not use the confusing nomination feature ;) [07:43] 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] asac: tsss :) [07:45] Hobbsee: the nomination doesn't disappear entirely, but since it's "wontfix"ed it falls off any relevant lists [07:45] ah right [07:45] Hobbsee: while also letting you track it again outside the release stream [07:45] (the flash crashers on that qa list are not in my hands btw) [07:45] yup [07:46] asac: are they in anyone's hands? [07:46] adobes ? [07:46] ogra_cmpc_: gnash, dude [07:46] oops [07:46] * ogra_cmpc_ hides his sleepy head [07:47] oh, maybe not all gnash [07:47] there are some libflashplayer.so-related bugs, maybe that's what asac was referring to [07:48] yeah sorry ... that comment was about adobe flash [07:48] 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] slangasek: does it crash? [07:49] if the joke isnt that there is no video behind theselinks indeed :) [07:49] lol [07:50] asac: it doesn't even show up in about:plugins (64-bit w/ nspluginwrapper) [07:50] ok, sorry ogra [07:50] cjwatson, nm [07:50] ok, any other business beyond bug lists? I'm going to continue looking through those and assigning [07:50] slangasek: *cough* [07:51] other business - yes [07:51] before everybody scatters, I'd like to highlight bug #210607 [07:51] 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] Launchpad bug 209429 in tzdata "/etc/timezone does not exist" [Medium,Incomplete] https://launchpad.net/bugs/209429 [07:51] bug 209783 needs syncing asap also :) [07:51] erm, btw these flash bugs are a year old [07:51] Launchpad bug 209783 in translate-toolkit "UVF exception / sync request for translate-toolkit" [Undecided,New] https://launchpad.net/bugs/209783 [07:51] (bug 197673 is my top priority but have made good progress on it of late and hope to have it closed soonish) [07:51] 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] slangasek: can you check if there is a libflashplayer-alternative.so setup in /usr/lib/xulrunner-addons/plugins? [07:52] 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] slangasek: I had no problem on my hardy systems over the weekend when us Sydneysiders were previously supposed to change... [07:52] 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] I'll keep an eye out for this weekend however, when are are changing. [07:53] 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] bryce: will there be change with the compiz blacklisting of ati cards? [07:53] me too [07:53] slangasek: (209783 is in your/release-team's court again, I think) [07:53] i have one [07:53] 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] cjwatson: correct, next on my todo list [07:54] ok [07:54] 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] asac: nope, no /usr/lib/xulrunner-addons/plugins/libflashplayer-alternative.so - so this is the bug, I guess? :) [07:54] 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] calc: right... :) [07:55] slangasek: has anyone verified if this problem exists just on upgrades, etc? [07:55] 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] slangasek: sorry, its flashplugin-alternative.so [07:55] ah it looks like it is hard problem to track down [07:56] bryce, any idea about the status of the geode breakage ? [07:56] 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] oh btw i want to let everyone know about this: http://live.gnome.org/GnomeGoals/XDGConfigFolders ;-) [07:56] ogra_cmpc_: wha? geode is broke too? [07:56] slangasek: ah ok [07:56] * slangasek runs far away from XDGConfigFolders [07:56] bryce, well, the general amd driver breakage [07:56] 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] ati ? [07:56] ogra_cmpc_: they plan for another release soon. [07:57] er, -amd, sorry [07:57] * cjwatson joins slangasek in running away; I think that's a horrible meme we shouldn't assist [07:57] basedir FTW! >:-) [07:57] ah :) [07:57] ETOOMANYDRIVERS [07:57] bryce, great, i just noticed that debian refused to add the fixes needed in xserver-xorg [07:57] (upstreams can do what they like, but distros moving stuff like that around is bad mojo) [07:57] the main problem (i think?) is migrating prefs/data [07:57] asac: oh, haha, I have that file, which points at the alternative, which points to gnash which isn't installed :) [07:57] the -amd -> -geode rename is going to save me so many typos ;-) [07:57] slangasek: hmm [07:57] asac: so that may be a gnash bug for failing to clear the alternative? [07:57] heh :) [07:58] cjwatson: yea we shouldn't move it ourselves that would be a large amount of work for little gain [07:58] slangasek: yes. though i think we --remove-all when no alternative is left [07:58] I think GNOME are wasting their time too, but hey ;-) [07:58] .cache is a decent enough idea, but not the rest IMAO [07:58] asac: but there is an alternative left, I have flashplugin-nonfree installed [07:58] asac: but the symlink is pointing wrong [07:58] slangasek: is that alternative set to manual mode? [07:59] asac: yes [07:59] slangasek: how old is your install? [07:59] asac: I don't /think/ it was set by me... [07:59] asac: originated as gutsy prerelease [08:00] slangasek: if you --remove the last alternative the alternative ends up in manual mode (no idea if that is a bug) [08:00] erm [08:00] i think really old packages didn't do --remove-all in that case [08:00] but gnash does it from what i can see ... lets llok at flashplugin-nonfree [08:00] I don't think packages are *supposed* to do --remove-all [08:00] this is not a bug I've ever heard of before in u-a [08:01] and doesn't match the documentation of --remove in the manpage [08:01] anyway, my flash curiosities needn't be fodder for #u-meeting [08:01] I was about to say, we're at time and I need more coffee. :) [08:02] slangasek: ;) [08:02] looks like other business has mostly dried up, anything else -> #ubuntu-devel; thanks all, adjourned [08:02] thanks [08:02] thanks [08:02] thanks [08:02] thank you! [08:02] cjwatson: for next meeting's agenda can you talk about post-release LTS support tasks? [08:02] thanks [08:02] bryce: good idea [08:02] thank you [08:02] thanks [08:02] goodnight [08:03] thanks :) [08:07] ogra_cmpc_: the patches that are needed for -amd are already in ubuntu, and debian has added them yesterday [08:07] oh, great [08:07] i had heard the debian maintainer didnt want to apply them at all [08:08] good that he changed his mind [08:09] he wanted to wait until it was merged upstream [08:09] ah [08:10] and now that most of the blockers for xserver 1.4 are fixed it, it can enter testing [08:10] and not wait for 1.5 [08:10] right [08:10] 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] heh [08:11] well, q-funk didn't actually help there.. [08:11] patches applied to which package? [08:11] xserver-xorg [08:12] kept pushing all the time and the maintainers got provoked [08:12] a set of three patches was needed to make the amd driver work at all [08:12] ah, ok [08:12] slangasek: yes, those have been in for some time now [08:12] he accepted one of the three (which didnt help at all) [08:13] fwiw, I was confused by the references to "the debian maintainer", since xserver-xorg is team-maintained in Debian :) [08:13] 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] 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] (... and telling me that they were provoked by q-funk also doesn't narrow it down much...) [08:14] he couldnt use gutsy because of that breakage [08:14] (or etch/lenny) [08:14] 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] many people in the thin client world are angry with us (even its not our fault, its upstream breakage) because of that [08:15] slangasek: ok, so I'll just pull the upstream fixes then? [08:15] tjaalton: yes, please [08:15] will do [08:15] we should probably not clutter the channel logs here btw and move over to -devel :) [08:16] heh yeah [08:16] if there's anything left :) [08:17] if geode works i'm as happy as i can be :) [08:17] I haven't seen q-funk complaining in weeks [08:18] *for === \sh_away is now known as \sh === Seveaz is now known as Seveas === dholbach_ is now known as dholbach === asac_ is now known as asac === Seveaz is now known as Seveas === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === \sh is now known as \sh_away === \sh_away is now known as \sh === johnc4511 is now known as johnc4510 === \sh is now known as \sh_away === encryptz is now known as atoponce === atoponce is now known as encryptz [19:01] hello [19:01] Hey! [19:01] hi [19:04] #startmeeting [19:04] * ogasawara_ waves [19:05] hi hi [19:05] hm, no bot today? [19:05] anyway, welcome all! [19:06] jcastro: here? [19:06] sorry I'm late :) [19:06] Hello! Is it 1900? [19:07] bdmurray: i'm wondering the same... [19:07] arg! [19:07] probably that's why evolution didn't tell me anything [19:07] 19:07 [19:07] why didn't anyone stop me? :) [19:07] oh yeah, we switched time [19:08] davmor2: but not UTC [19:08] now is 20 UTC, right? [19:08] ah [19:08] * liw starts recruiting people to the Alliance Against DST [19:08] the meeting page clearly says UTC (and I wrote it ...) [19:08] so we already had the meeting an hour ago, right [19:09] no, it's an hour from now [19:09] That's what I'd thought. [19:09] it's 18 UTC now [19:09] seeing that we're all here, shall we go ahead? [19:10] I'm fine with now [19:10] +1 [19:10] yeah go for it [19:10] apologies to those who miss it and are reading this in logs ... [19:11] [TOPIC] New team member introduction: Chris Gregan, Mobile QA [19:11] everyone wave to cgregan! [19:11] Hello team [19:11] cgregan, hi [19:11] welcome cgregan! [19:11] I thought UTC was bst [19:11] hi cregan! [19:11] Hello cgregan [19:11] Chris has been keeping busy getting up to speed with the mobile team [19:12] He'll be doing bug management and testing on mobile [19:12] brave man well done :) [19:12] rock on! [19:13] cgregan: you can find QA team members in #ubuntu-bugs and #ubuntu-testing usually [19:13] heno: good to know...I will add them to my, growing, list of irc channels [19:13] great [19:13] cgregan: it only gets bigger :) [19:14] I don't see jcastro here just yet, so let's take topic #3 for now [19:14] [TOPIC] Test plan review for RC/Final [19:15] davmor2: has been updating the Xubuntu and KDE4 plans with nice graphics :) [19:15] 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] 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] davmor2: rock! [19:16] davmor2: Can you send link to plans? [19:16] cgregan, https://wiki.ubuntu.com/Testing/Cases is that what you mean? [19:16] liw: perfect [19:17] thanks [19:17] cgregan comes from a backgound in mostly proprietary software QA [19:17] 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] cgregan: I'd appreciate your take on these plans [19:18] heno: sure...I'll review and update the team [19:18] davmor2, awesome work [19:19] liw: the kde4 was the other layout but we agreed it was easier with images :) [19:19] kde4 is mostly text layout hightlighting things that are important [19:19] to many t's in highlighting :) [19:20] I think jcastro may have fallen victim to my scheduling gaffe :( [19:21] Should have a test case for ubiquity-only? [19:21] let's cover the upstream bug topic now and I can have a phone call with him later [19:22] bdmurray: is it very different from Live -> ubiquity? [19:22] We should make sure both paths get tested indeed [19:22] Only in terms of accessing it. [19:22] bdmurray: you can't really do that with ease because there are several versions of ubiquity each slightly different [19:22] and it's important to exercise both code paths [19:24] davmor2: but on a given CD is there much difference in running ubiquity with 'Install only' and Live -> Install? [19:24] The installation process does not change but the amount of memory required for ubiquity only is much less. [19:25] I'm hesitant about adding a test case for every variation because we quickly get too many [19:25] heno, I was thinking the same thing [19:25] though this may be a valid case [19:26] 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] Perhaps checking with cjwatson or evand would be best then. [19:26] a stop-gat might be to ask people to add a tracker comment about which path they used [19:27] 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] 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] that covers every aspect then [19:30] yep, people usually have 3 or so partitioning methods assigned on a given CD and should spread that over start paths [19:30] davmor2: can you add that? [19:30] bdmurray: thanks for pointing that out [19:31] [TOPIC] Upstreaming bugs; wiki guides and bugdays [19:31] 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] I understand there were some mixed views of the value of the upstream linking yesterday [19:32] By the way https://wiki.ubuntu.com/Testing/Cases/Wubi isn't linked to on the main page. [19:32] bdmurray: it is at the bottom ;) [19:32] I want to refresh that landing page actually [19:32] it's not very inviting [19:32] Oh, I was just looking at the top section. [19:33] It should be added, you are right [19:33] * heno takes an action to tidy that page up [19:33] heno: Do you know what the negative opinions are? I haven't heard them. [19:33] bdmurray: it's on the list we will probably lose winfoss [19:34] davmor2: cool, thanks! [19:34] bdmurray: basically seb128 and i were talking that the bugday caused us more noise than anything [19:34] and it'd be nice if it happens during another time of the release process [19:35] I think the problem is that the upstreaming on gnome bugs was already quite good [19:35] noise in what sense? more bugmail or something else? [19:35] yeah lot of bugmail [19:35] and it's difficult to improve on that for people with less experience [19:35] we already have a lot daily ;-) [19:36] I think some of the added links may not have been correct [19:37] yeah and then we have to correct them [19:37] Okay, both of those points make sense to me. Are the bug watches useful though? [19:37] Or rather bug watches in general useful? [19:37] I'm also wondering if picking this low hanging fruit isn't really just sidestepping the issue [19:38] filing bugs upstream well is hard and requires insight into that upstream's bug landscape and culture [19:39] we should probably rather focus on packages with very few bugs filed/linked upstream [19:39] start fling/linking those and gaining the experience and connections [19:39] I think there are 2 separate issues though. 1) filing bugs upstream and 2) linking bugs upstream. [19:40] bdmurray: you mean link bugs that someone else has already marked as an upstream issue? [19:41] for point 2 I mean adding a bug watch for an existing upstream bug report [19:41] 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] While it still requires a fair bit of knowledge - it can require less than actually filing it upstream. [19:42] but both should be part of the same workflow right? [19:42] the difficult of filing upstream depends a bit on the cost of doing a bad job at it [19:43] IOW - how upset does upstream get if you file a poor bug or dupe? [19:43] 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] So while they are part of the same workflow they have different degrees of difficulty. [19:44] 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] this will depend on the upstream and our approach [19:46] bdmurray: I mostly agree. but how many of the linkable bugs are there? is it worth focusing on as an approach [19:46] ? [19:47] 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] bdmurray: do you think we should do more 'upstreaming' bug days, or should we make it a component of bug days generally? [19:48] heno: I'm still looking at the numbers as to how many linkable bugs there are. [19:49]