[00:00] ogra, night ;-) [00:00] :) [00:02] ompaul: ogra is a bot, he doesn't need to sleep. [00:02] haha [00:02] stgraber, he just needs to smoke and organise flash hugs ;-) [00:02] no i pushed my cmpc release candidate yesterday ... i feel useless now [00:02] ompaul: yeah :) [00:02] ogra: go to #ltsp, lots of work there :) [00:03] yeah, on my list :) === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 06 Aug 20:00 UTC: Maryland LoCo IRC | 07 Aug 12:00 UTC: Ubuntu Mobile Team | 07 Aug 14:00 UTC: Ubuntu Java Team | 08 Aug 00:00 UTC: Americas Board | 08 Aug 04:00 UTC: Ubuntu MOTU | 14 Aug 12:00 UTC: Ubuntu Mobile Team === t is now known as tomaw__ === tomaw__ is now known as t === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 06 Aug 20:00 UTC: Maryland LoCo IRC | 07 Aug 12:00 UTC: Ubuntu Mobile Team | 07 Aug 14:00 UTC: Ubuntu Java Team | 08 Aug 00:00 UTC: Americas Board | 08 Aug 04:00 UTC: Ubuntu MOTU | 08 Aug 15:00 UTC: Ubuntu Release === ApOgEE- is now known as apogee-x === Rafik_ is now known as Rafik === dholbach__ is now known as dholbach === thekorn_ is now known as thekorn === doko_ is now known as doko [17:58] hello everybody! [17:59] hey! [17:59] hey! [17:59] hey! [18:00] * pedro_ hugs nxvl [18:00] nxvl: nice MOTU video ;-) [18:00] pedro_: thanks [18:00] welcome everyone! [18:00] #startmeeting [18:00] Meeting started at 12:04. The chair is heno. [18:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:01] [TOPIC]: Post Hardy.1 SRU verifications - help needed [18:01] New Topic: : Post Hardy.1 SRU verifications - help needed [18:01] There are quite a few SRUs in need of verification in both main and universe [18:02] http://people.ubuntu.com/~sbeattie/sru_todo.html and http://people.ubuntu.com/~ubuntu-archive/pending-sru.html [18:02] LINK received: http://people.ubuntu.com/~sbeattie/sru_todo.html and http://people.ubuntu.com/~ubuntu-archive/pending-sru.html [18:03] and that's after a number have already gone through. [18:03] I actually think we should question whether all these are SRU-worthy [18:03] whether they really meet the serious breakage or regression criteria [18:04] well, it's not really the QA teams decision exactly [18:04] but perhaps we can do some sort analysis to help the SRU teams decide better [18:04] But we have a voice in that [18:04] sure [18:04] heno, SRU policy changed a bit, even small patches can become a SRU nowadays (as per wiki.u.c/SRU page) [18:04] we should encourage thouse guidelines to be followed [18:05] I personally think QA efforts might be most useful in poking people in these situations [18:05] getting 2 + votes should not be difficult [18:06] right. I'll ask around a bit and report back [18:06] in the meantime it would be great to have help in checking these [18:06] Some of the ones, particularly update-manager, have ppc specific issues (the move from being a supported platform to ports) [18:06] you should have at least the original reporter and sponsor [18:06] I think that a QA voice in SRU would certainly help: both SRU teams seem overburdened by the current processes (from an external perspective) [18:07] I suspect it mostly comes from work that just missed the Hardy.1 deadline [18:07] sbeattie: is that bug marked as hw specific ? [18:07] Maybe, but lots of people doing SRU weren't paying attention to Hardy.1 [18:08] Hardy.1 is not relevant to Universe. [18:08] pedro_: they're not, I was wondering actually whether to. [18:09] persia: I agree about overburdening. I was not able to keep good situational awareness on what I should pay attention to and be effective. One reason why I quit motu-sru. [18:09] ScottK: true, and many of them pre-date .1 [18:09] I'll blog a "QA wants you!" today for the SRU verifications [18:09] pedro_: or to have a specific ppc tag. [18:09] LaserJock: great! [18:09] LaserJock: could you mail the devel list as well? [18:10] heno: will do [18:10] moving on [18:10] in the past, MOTUs wrote mails on ubuntu-motu about -proposed updates to be tested, I don't think they were useful, but gave a little more attention to the SRU process. [18:10] I'm going to switch topics 2 and 3, which seems to make sense here [18:11] [TOPIC]: Introducing Tom Berger (intellectronica) - Launchpad Bugs contact [18:11] New Topic: : Introducing Tom Berger (intellectronica) - Launchpad Bugs contact [18:11] hi everyone [18:11] intellectronica: are you here? [18:11] hey intellectronica [18:11] intellectronica: nice nick :-) [18:11] hello :) [18:11] intellectronica: hi [18:11] intellectronica: hey dude! welcome to our world :) [18:11] Tom accepted my invitation on short notice, thanks! [18:11] intellectronica: welcome! [18:11] tuxmaniac: cheers. bonus points if you know where it's from ;) [18:11] hey intellectronica welcome ;-) [18:12] He's a developer on the LP bugs team [18:12] thanks, everyone, for the warm welcome [18:12] intellectronica: care to expand a bit on that? [18:12] He's also worked on Blueprints which are really cool! [18:13] starting this month, a major part of my role as part of the launchpad team, and in particular as part of the malone team, would be to work with ubuntu and the qa team to make sure that launchpad serves their needs and that questions and requests are easy to communicate [18:14] great, which brings us to: [18:14] Wonderful news indeed! [18:14] that means that in many cases i will be working directly on parts of launchpad that concern your work, but more importantly, it means that i am always available for you [18:14] [TOPIC]: LaunchpadBugsFeaturePriorities - call for input. [18:14] New Topic: : LaunchpadBugsFeaturePriorities - call for input. [18:15] see https://wiki.ubuntu.com/QATeam/LaunchpadBugsFeaturePriorities [18:15] thanks to everyone who has provided feedback so far [18:15] intellectronica: note the two additional items [18:16] we also separated out the HWDB stuff as there is a dedicated person working on that [18:16] intellectronica: awesome! thanks [18:16] heno: noted, though both are quite general, and are indeed on the general list of things we want to achieve in the coming period [18:17] intellectronica: have the general lists been published? [18:17] intellectronica: Current performance is a real killer. [18:17] or are there plans to? [18:17] the hwdb stuff is being worked on with abel and I understand that bjorn is open to discussions on this topic [18:17] specifically, regarding speed, please feel free to bug me if you feel that something isn't fast enough. more often than not we wouldn't notice until it actually times out [18:18] intellectronica: Generally LP web U/I is so slow it's practically unusable. [18:18] we probably work with bugs differently than most projects, often opening hundreds in a day [18:18] which is why performance is such an issue [18:18] ScottK: i guess that's more true for ubuntu, which has very big sets of bugs to work with [18:19] intellectronica: more true for Ubuntu than for what? [18:19] ScottK: again, the best way for you to help us remedy this is by pointing out specific cases (even if there are many of them) [18:19] LaserJock: more true for ubuntu than for smaller projects [18:19] LaserJock: smaller projects that use LP [18:19] oh, I see [18:19] * LaserJock was confused for a sec [18:19] intellectronica: there's an always reproducible timeout when you select "Show bugs that are not known to affect upstream" is that known? [18:19] intellectronica: I don't know of any cases that aren't. When it takes the database 4 seconds just to find the data for a single page, it's far to slow. [18:20] and for people who look at few bugs, whereas QA people tend to look at lots [18:20] pedro_: it is known and a fix is being worked on [18:20] intellectronica: great, thanks! [18:20] * ScottK decides to go back to $WORK before he gets some momentum on the topic and makes intellectronica feel unwelcom. [18:21] heh [18:21] regarding the speed i don't have issues with that [18:21] It may be that APIs+Leonov will help many people here [18:21] bugzilla takes more time to load anyways [18:21] and lp its way better to show pages with hundreds of bugs on it than bugzilla [18:21] but that's just me maybe [18:21] a web app will always be slower than a real one [18:22] yes yes yes [18:22] but indeed having some more tweaks there would be great [18:22] any other comments on the list other than speed? [18:22] actually, i think that in this cases the slowness usually comes from the database. there are efforts to move to a better scalable architecture, but in the meantime, the best we can do is look at specific cases under the microscope and try to optimize them [18:23] Work fine for me :) [18:23] I think that the tag policy should be prioritize [18:23] right now it is only pri 13 of the list [18:23] Tags are a lost cause. [18:23] intellectronica: I really like how landscape designed their backend to scale across multiple databases instead of relying on one single database [18:23] but they are extremely helpful when used correctly [18:24] (or sort of) [18:24] broadly, I think it's valuable to try to help people to create/make higher quality bug reports [18:24] ara: ok, noted [18:24] cr3: yes, we're learning and adopting a lot from how landscape is doing things [18:25] oh ara: you also have to suggest something that should have its priority decreased ;) [18:25] lol [18:26] are complete activity logs really a #4 when we get the APIs? [18:26] intellectronica: I want to bear gustavo's children :) [18:26] I think so, personally [18:26] I was tempted to put it #1 [18:26] I assume the item here is about the web version [18:26] but it's more for me than for general users [18:26] heno: I think it would apply for both actually [18:27] Having package assignment in the activity log would be useful [18:27] intellectronica: was wondering if there's any support amongst the user base for additional first class elements; for example the elements in https://wiki.ubuntu.com/Bugs/Description [18:27] the API may not give all the activity log either, I'm not sure [18:27] ok [18:27] I've just seen a number of bugs that clearly had a history, but the activity log is blank [18:27] having the activity log be useful as an audit log of operations performed would be very useful. [18:27] sbeattie: not that i know, but if there's a need we should discuss it [18:28] and that's very frustrating when trying to put the history together or trying to see who did what [18:28] LaserJock: the api currently doesn't expose bug activity log (or bug searching, or bug filing). but it will very soon [18:28] I don't understand why not losing history is a "feature". It's a bug and they should fix it. [18:28] i am back [18:28] sorry [18:28] for instance, for SRU tracking, we'd like to know who approves the SRU or changes the status [18:29] having a good ways of getting complete history is important [18:29] intellectronica: in particular, I'd like to see testcase as a first class element, perhaps as an attachment type, to make automatically pulling them out easier. [18:29] as you can see, fixing the activity log is something we worked on speccing and estimating. it's quite expensive in terms of effort, but i personally am very much in favour of prioritizing it high [18:30] sbeattie: that's an interesting idea (extending the list of attachment types). maybe that's the way to do that [18:30] ok, there seems to be consensus around that [18:31] sbeattie: for other types of metadata attachments would be less aprropriate, though [18:31] in fact, let's go through the top 5 from 'my version' of the list and get views [18:31] intellectronica: extending it to what types exactly? [18:31] #1 Package-specific reporting guidelines [18:31] cr3: test case, for example [18:31] sbeattie: test cases as bug attachments would be awesome. would you distinguish test steps from test scripts? [18:32] My aim there is to improve new reports being filed [18:32] heno: do you think reporting test cases would help improve that? [18:32] I think that improving new reports is the key point, the welcome email to new reporters is a great idea [18:33] and easy to implement [18:33] I don't understand why that isn't just part of the signup process. [18:33] I don't get the point of th email to new reporters [18:33] cr3: it may be a bit advanced for filers [18:33] Launchpad *should* be self-descriptive [18:33] hm, so I think that test cases would be an awesome idea but I think it would only be interesting to a minority of people out there, so perhaps concentrating on the welcome email to reach the larger masses would be time better spent [18:33] LaserJock: i think it's a good way to get the attention of new bug reporters and introduce them to the process [18:34] intellectronica: I would submit that if that's needed something else is wrong [18:34] The idea is that you would get an email the first time you file on a given package with info on how to better file bugs on it [18:34] and info about what will happen next [18:34] oh good lord, on every package? [18:34] heno: Why isn't that in the U/I? [18:34] heno: oh, a different email on a per package basis!? interesting... [18:35] i'm not sure doing this for every package makes sense. i would do this for ubuntu globally [18:35] ScottK: because people don't read web pages ;) [18:35] and maybe for some packages like firefox [18:35] people don't read email either [18:35] heno: They aren't going to read the mail either [18:35] intellectronica: I think heno would have a few key packages in mind [18:35] that could be [18:35] I think a per-package thing is more interesting in the UI. A per-project thing might be interesting in email. [18:35] I certainly don't want to get a new email for every bug I file (I very rarely file two bugs in the same package) [18:36] cr3: right, as long as we restrain ourselves so that we don't become abusive to our users [18:36] persia: you would only get an email the first time you report a bug against a specific package [18:36] I could see giving an email with useful wiki pages (we have quite useful documentation in the BugSquad) on first filing [18:36] so if we keep guided filing at #1 we should demote the email one which is similar? [18:36] cr3: Which for me, is likely to be every bug I file. [18:36] I much prefer guided bug filing as a solution to that problem. [18:36] persia: yeah, that would be big-time spam [18:37] Personally I think sending mail to tell me something you could have put on the web page I was at when I didn't ask for the mail borders on abusive. [18:37] OK, I'll demote that as I seem to be the only supporter of it :) [18:37] #2 Duplicate-detection inside launchpad [18:37] that should make triage easier [18:38] I like it, but think other things should be higher than it [18:38] this is basically using the new-bug-filing dupe-finder on exisiting bugs [18:38] it sort of depends on how well the dup detection works [18:39] LaserJock: it works pretty well [18:39] well [18:39] what do triagers think? [18:39] One of the use cases which makes ubuntu a different user of launchpad than most projects hosted on it, is that it is an aggregation of packages, and subgroups of those packages could/would be useful (weather report, per package bug filing info) [18:39] I use a fake new report sometimes to look after dups [18:39] I guess I don't understand why if the dupe finder could find it, it isn't already found. [18:39] could it be also look into the summary and not only in the title? (which is what's currently the dup-finder is doing) [18:39] one of the things I'm concerned about with it what is done once a dup is detected? [18:40] if we have to go back and retriage dups then I'm not sure how much we save [18:40] ScottK: the only case is where the bug reporter ignored it [18:40] Perhaps if the UI offered a clickable list of possible dupes when selecting a duplicate, rather than just asking for entry? [18:40] ScottK: because the bug you are looking for may have been filed afterwards, it's description changed, etc [18:40] That might be helpful without being disruptive. [18:40] so how would this be implemented? [18:41] intellectronica: In that case I think it's actively harmful. [18:41] would it be flagged somehow as "possible dup"? [18:41] or the filer may not have wanted to dupe it for some reason [18:41] LaserJock: yes, that's the idea. to make it easier to search for 'maybe dupes' [18:41] persia: ohhhh, I l ike that [18:41] And I'd prefer not to have some automagic over-ride what the reporter decided. [18:41] persia: that would be good, it's what the GNOME Bugzilla does [18:42] it's not an automatic thing, just a search feature [18:42] ok, that's cool [18:42] I like persia's idea of it [18:43] me too [18:43] though I think it's more of a "handy for us" than a "helps make reports higher quality" which I sort of perfer in generall [18:43] indeed [18:43] As a search feature, I think it might be useful, but not high priority. [18:43] ok, that can be lowered a bit too it seems [18:44] 3 and 4 we covered [18:44] ScottK: we were thinking/hoping that it would be relatively easy to implement, given that the dupe detection capability alreayd exists. [18:44] #5 Bugtask forwarding relationships [18:44] hmm, I didn't quite get that one [18:44] intellectronica: can you explain that one more? [18:44] What were 3 and 4? [18:45] 3: email to new reporters 4: full activity log [18:45] #3 Email first-time bug-reporters #4 activity log [18:45] OK. [18:45] ScottK: https://wiki.ubuntu.com/QATeam/LaunchpadBugsFeaturePriorities has the order [18:45] LaserJock: basically, it's a way to refine the way bug tasks are raised [18:46] LaserJock: the suggestion is to have 'phantom' bug tasks on some bugs, which you can confirm or deny [18:46] IMO it's important to be able to say 'this bug does not need upstreaming' [18:46] hmm, that sounds initially easy to abuse [18:46] What's the use case for this? [18:47] or 'for this one we don't know yet' [18:47] I see [18:47] For people who specialise in working with upstream, forwarding issues [18:47] so we're trying to figure out how to sort packages into "Ubuntu specific", "May affect upstream", and "Affects Upstream" ? [18:48] yes [18:48] LaserJock: exactly. [18:48] i like that idea ;-) [18:48] hmm [18:48] I think being able to remove ones that shouldn't be there is far more important. [18:48] Is this just a UI change for "Also Affects..." ? [18:48] well I would initially say that that could be done via tags [18:48] ScottK: with this feature implemented, you'll be able to remove them before they are even created! :) [18:48] the number of ubuntu-specific bugs is generally quite low [18:48] so if you were to tag those [18:49] and have negative tag searches [18:49] right, it shpuld be possible to change it between any of those 3 states [18:49] you'd have "ubuntu specific" and "non-ubuntu specific" [18:49] Having a list of Ubuntu-specific bugs would likely be interesting to some subset of developers [18:49] LaserJock: It's not so easy. Just because it's not a packaging bug, doens't mean I won't patch it if I can. [18:49] We already have a tag for 'packaging' bugs. [18:49] ScottK: why is it not that easy [18:50] LaserJock: sure, but you won't have to connection to upstream proejcts in cases where an upstream task is due [18:50] we're just talking about tagging here [18:50] it could also be a code bug we introduced [18:50] I never said anything about what kind of bug it is [18:50] heno: Those tend to fall under "packaging" as well, as in "some patch oughtn't be applied" [18:50] I just said we can tag ubuntu vs. non-ubuntu bugs [18:50] for many packages we know what the relevant upstream project is, so it would be nice to be able to use that relation effectively [18:51] intellectronica: I don't get how this spec would improve that? [18:51] That reminds me, I don't see "Inheriting upstream links between releases" on the list. Is that an option? [18:51] does it make it easier to file a bug upstream? [18:52] Personally, I'd like clearer disambiguation between upstream and Ubuntu tasks when upstream uses LP. [18:52] I find the an upstream that uses LP makes life much more confusing for me. [18:52] LaserJock: when a bug is filed on an ubuntu package, you will get a suggestion for where it should be reported upstream, and you'll be able to decided whether to file it, or indicate that it's ubuntu-specific [18:52] it makes it easier to triage the bugs that _may need filing upstream_ [18:52] Or even when someone randomly registered the upstream project in LP and didn't set a foreign bug tracker. [18:52] ScottK: how so? [18:52] intellectronica: oh, and how would that look in the UI? [18:52] because you start with a big unknown pile and put bugs in two other piles [18:53] First, is upstream is external, I just get status changes. If they use LP, I get every single effing piece of bugmail and no way to turn it off. [18:53] And the difference between that and Ubuntu related comments is very small. [18:53] LaserJock: using 'phantom tasks'. lines in the bug task table that are clearly indicative of their requiring confirmation. also in search [18:53] where as now it's 'upstream' and 'ubuntu spec + don't know' [18:53] Also, I think most triager's don' t know enough to know what should go upstream. [18:53] intellectronica: we've had a lot of people who abuse the upstream stuff already, who can confirm these? [18:54] Even more specifically what should go to Debian and what should go to the eventual upstream. [18:54] LaserJock: the same people who can set Triaged (though of course we can discuss that when implementing) [18:54] Making this to easy is a recipe for disaster. [18:54] Well, making this easy may impose a large training burden. [18:55] No. [18:55] Making it easy invites abuse. [18:55] If people were sufficiently trained, they could handle it anyway. [18:55] ScottK: well, i believe that real access control is much better than obscurity. if too easy means that you get lots of junk it means that we didn't get the permissions right [18:55] so is this just making "Also affects project/distribution" easier to use by assuming we want the tasks and letting us confirm or not? [18:56] LaserJock: sort of. it also helps marking bugs as ubuntu-specific [18:56] Fundamentally I think this entire U/I piece is pretty broken anyway. [18:56] intellectronica: how so? [18:56] LaserJock: if you mark a bug as not affecting upstream, launchpad will remember it [18:56] intellectronica: There aren't so many of those: it's typically only for ubuntu-local packages or when we broke something. I wouldn't like to assume that's the general case. [18:57] basically I think the assumption is that *everything* is assumed to be Ubuntu-specific until somebody explicitly finds that it's not [18:57] but hey, it could be that the best thing to do is de-prioritize this feature. there are definitely many other features we could consider instead [18:57] ideally we indicate that by filing the bug upstream and opening a task for it [18:57] (Mind you, I think "Also Affects..." could use work, I just don't want to optimise for the "Ubuntu-only" case, as I think it's rare) [18:58] It's seems we need more details on the implementation before taking a clear view on it [18:58] yeah, I'm still not sure what it's going to do [18:58] ok, any other items on the list we should cover? [18:58] I'd love a feature where I don't have to go through the useful project registration stuff to link a bug. [18:58] higher or lower priority [18:58] heno: ok. shall we make it an action for me to upload a spec so that we have something more concrete to discuss? [18:58] usful/useless [18:59] intellectronica: yes please [18:59] cool [18:59] in general I think tags are a pain point [18:59] ScottK: get jcastro to do it for you ;) [18:59] heno: It's a useless barrier [19:00] I'd like to discuss the qualifying bug reporters one. [19:00] I think it should be removed. [19:00] LaserJock: and is official tags the right answer [19:00] It's very un-Ubuntu to tell people the don't know enough to report bugs. [19:00] I think it's also actively harmful to register projects in Launchpad just for bug tracking [19:00] heno: part of it [19:00] Agreed. [19:00] we've also discussed better viewing of tags [19:00] If I put my upstream hat on for a moment, I find them very troublesome [19:01] i.e. sorting by number of bugs tagged rather than alphabetical [19:01] and having a threshold number [19:01] right qualifying bug reporters will clearly be controvertial [19:01] They show up in google searches and look like the upstream home when they aren't. [19:01] LaserJock: by the way there is a greasemonkey script for that now [19:01] bdmurray: cool, we just need to get that into LP proper :-) [19:02] bdmurray: Sure, but isn't this the opportunity to not need that anymore ? :) [19:02] I don't feel strongly about it, but assumed it would raise the quality of bugs on average, though at a cost [19:02] persia: that's why I qualified it with by the way [19:02] henkjan: what would? [19:02] bah [19:02] Oh. I thought you were just passing FYI. Sorry for confusion. [19:02] heno: ^^ [19:03] 'qualifying bug reporters' [19:03] oh right [19:03] yeah, I think that's a terrible idea [19:03] and really hope it never sees the light of day ;-) [19:03] ScottK wants it removed, as does LaserJock [19:03] any other views? [19:03] I can't imagine what upstream's would think [19:04] "I can't file bugs on my own software???" [19:04] I'm with ScottK on this too, it's going to be very controversial for upstream people [19:04] ok, I'll set that to '-' then [19:04] thanks [19:04] I mean, it's an interesting idea [19:04] anything else on the list? [19:05] I'd also think U/I for submitting to upstream is not a good idea. [19:05] but I don't think there's any real metric that will work to figure out what "qualified" is [19:05] Perhaps the redirection can be part of the guided-bug-filing process, so it is noted but not enforced. [19:05] it's meant to give you a template basically hat you can paste upstream, not fully automatic [19:05] I like the idea of an e-mail after the first time a user reports a bug with Ubuntu, but I think we should take it a step further. Would it be possible to add some sort of HELP button to the "Report a bug" page? Perhaps something like https://help.ubuntu.com/community/ReportingBugs would be very helpful to first time bug reporters. [19:06] JonPackard: Link on a web page or "Click here if you want us to mail you more information", but not automatic. [19:06] I'd be a fan of search filtering. Sometimes someone asks me about classes of bugs that keep popping up in their searches, and I have to read a bit to understand how to suggest they search differently to find what they seek. [19:06] JonPackard: that could be worked into 'guided filing' [19:07] heno: I guess I have a hard time envisioning a template that would work for more than one upstream. [19:07] ScottK: it needs to be tailored for each, indeed [19:07] I put "Capture Distro Series When Filing Bugs" and "Better package name UI guidance" on my list [19:08] I think it would be good to help reporters get good information the first time [19:08] how often do we see triagers asking "what version of Ubuntu and package are you using?" [19:08] heno: Seems to me like a huge amount of work for little to no payoff (generally the same people that are qualified to upstream bugs know how to use the upstream bug tracker) [19:08] persia: you want "Explicit Search Filtering" raised a bit? [19:08] LaserJock: Agreed. [19:08] and then we have quite a few reports with no package associated that I think we can get rid of [19:09] we don't do enough upstreaming today though [19:09] many bugs are just lingering with us [19:09] heno: I don't help in #ubuntu-bugs as much as I'd like, but it's certainly something that would make helping some of the triagers easier for me. [19:09] persia: ok, thanks [19:09] On the other hand, it doesn't affect me personally, and I'm happy that it got a number if everyone else feels it's not so important. [19:10] heno: I think not sending everything upstream is better than sending them lots of junk that leads to Ubuntu bugs getting ignored. [19:10] heno: I believe the lack of upstreaming is mostly a cultural/social issue [19:10] LaserJock: right, there should be room for those now that we have demoted a few [19:11] btw, LaserJock's prioritised list was helpful - it'd be great if a few more people did that [19:11] the problem is that upstreaming is almost by definition a pretty hard thing to do [19:11] that way I can try to reconcile the different lists [19:12] it is, but we should try to make it easier where we can [19:12] agreed [19:12] let's try to wrap up the meeting [19:12] keep using the mailing list [19:12] it's all good stuff! [19:13] yes, productive meeting for sure [19:13] any other business? [19:13] poor intellectronica ;-) [19:13] (quickly) [19:13] ok, thanks all! [19:13] err [19:13] #endmeeting [19:13] Meeting finished at 13:17. [19:13] we can continue in #ubuntu-quality [19:13] crap, I wanted to mention that daily builds are being tested now :) [19:14] thanks, heno (and everyone) [19:14] heno: The hard part with upstreaming isn't the filing, but the knowing if and when to do so and what to say. [19:14] thanks intellectronica and everyone! [19:14] thanks all [19:14] ScottK: and followup, IMO [19:14] ScottK: agreed, you need to spend some time learning about that upstream [19:14] when you file a bug upstream you become the new bug reporter [19:15]