== 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.}}}