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