Apr 15 09:04:58 <jlaska>	greetings folks
Apr 15 09:05:14 <jlaska>	okay let's kick things off ... rough agenda posted to https://www.redhat.com/archives/fedora-test-list/2009-April/msg00978.html
Apr 15 09:05:17 <adamw>	wow, that's a very emo nick.
Apr 15 09:05:30 <f13>	?
Apr 15 09:05:38 <adamw>	oh, sorry, thinking out loud.
Apr 15 09:05:41 <viking_ice>	seconds f13: ?
Apr 15 09:05:50 <jlaska>	I'll be posting minutes/tasks to https://fedoraproject.org/wiki/QA/Meetings/20090415
Apr 15 09:07:20 ---	jlaska has changed the topic to: Fedora Quality Assurance Meeting | Previous Meeting follow-up https://fedoraproject.org/wiki/QA/Meetings/20090408
Apr 15 09:07:40 <jlaska>	[jlaska+adamw] mediawiki semantic update (packaging and hosting)
Apr 15 09:08:08 <jlaska>	I've ping'd out to the infrastructure folks for a snapshot of the fedoraproject.org/wiki to play with in a private mediawiki+semantic instance
Apr 15 09:08:15 <wwoods>	are you reviewing *last* week'
Apr 15 09:08:21 <jlaska>	yeah ...
Apr 15 09:08:32 <wwoods>	er. last week's review? I'm all confused. ok sorry.
Apr 15 09:08:53 *	wwoods not on his normal workstation, feels all out-of-sorts
Apr 15 09:09:13 <jlaska>	no worries ... I carried fwd the tasks into todays agenda (https://fedoraproject.org/wiki/QA/Meetings/20090415#Previous_meeting_follow-up)
Apr 15 09:09:42 <jlaska>	I suspect mediawiki+semantic will likely mature post F11 ... just too much to juggle to get that going at present
Apr 15 09:09:59 <jlaska>	unless there are other ideas/suggestions, I'll likely keep tabs on that and pursue post-F11
Apr 15 09:10:24 *	jlaska moves to next item
Apr 15 09:10:27 <jlaska>	#  [jlaska] - reach out to pmuller on packaging rhtslib
Apr 15 09:10:45 <wwoods>	yeah I think we're getting too close to F11 for a lot of our longterm development stuff. as always.
Apr 15 09:11:08 <jlaska>	wwoods: true true :(  I feel good we have some next steps lined up, but I suspect it'll have to wait
Apr 15 09:11:33 <jlaska>	re: rhtslib ... I was hoping to get pmuller to join the meeting today as a "special guest" ... but was unable to get in touch with him
Apr 15 09:11:50 -->	Nirmal (n=npathak@nat/redhat-in/x-a28ee369532bd59f) has joined #fedora-meeting
Apr 15 09:11:57 <jlaska>	wwoods and I ping'd pmuller earlier this week, hopefully we'll have an update near th end of this week
Apr 15 09:12:12 <jlaska>	wwoods: do you have any rhtslib packaging news?
Apr 15 09:12:25 <--	mether_ has quit (Read error: 54 (Connection reset by peer))
Apr 15 09:13:02 <wwoods>	jlaska: nothing to report
Apr 15 09:13:03 <--	nphilipp has quit ("Leaving")
Apr 15 09:13:45 -->	mether (n=sundaram@nat/redhat-in/x-e5036da7f58fd769) has joined #fedora-meeting
Apr 15 09:13:56 <jlaska>	wwoods: okay ... we'll both follow-up later this week
Apr 15 09:14:10 <jlaska>	#  [jlaska] - improve the kickstart file used for generating test day live images
Apr 15 09:14:25 <jlaska>	last week there was some list discussion around improving the kickstart file used for generating the test day live images
Apr 15 09:15:02 <jlaska>	I spoke to jeremy about adding a kickstart script to the spin-kickstarts git repo ... jeremy suggested that might not be the best fit and instead suggested this: https://fedoraproject.org/wiki/QA/Test_Days/Live_Image
Apr 15 09:15:12 <jlaska>	which is linked to from the main Test_Days page under the FAQ
Apr 15 09:15:30 <jlaska>	it's nothing complicated, but I think meets the guidance supplied by adamw :)
Apr 15 09:15:37 <jlaska>	"keep it simple" :P
Apr 15 09:15:51 <adamw>	just reading
Apr 15 09:16:19 <adamw>	nice
Apr 15 09:16:29 <jlaska>	the kickstart sample posted still needs help in terms of creating a Test_Days:Current .desktop link and other suggestions from the list
Apr 15 09:16:39 <jlaska>	but it's a start ... and anyone with tips/ideas is welcome to add on
Apr 15 09:16:44 <adamw>	that looks like a very sensible way to do it
Apr 15 09:16:53 <adamw>	maybe send a mail to the list about it?
Apr 15 09:17:05 <jlaska>	adamw: ah doh!  good idea, thank you
Apr 15 09:17:47 <jlaska>	okay next up ...
Apr 15 09:17:50 -->	thomasj_ (n=thomasj@e180186163.adsl.alicedsl.de) has joined #fedora-meeting
Apr 15 09:18:00 *	jlaska takes a TODO for mailing fedora-test-list@
Apr 15 09:18:01 <jlaska>	#  [adamw] - send details of nss rawhide issue to warren for posting to rawhidewatch.wordpress.com
Apr 15 09:18:22 <f13>	afaik all the nss issues have been resolved as of last night
Apr 15 09:18:47 <f13>	there were odd arch issues, then there was a FIPS mode issue in installer, but all of that is resolved AFAIK
Apr 15 09:18:51 <adamw>	and I did send the info, and it got posted
Apr 15 09:19:04 <--	thomasj has quit (Nick collision from services.)
Apr 15 09:19:08 ---	thomasj_ is now known as thomasj
Apr 15 09:19:12 *	jlaska is behind on his planet reading :(
Apr 15 09:19:21 <adamw>	f13: the main point of the note on rawhidewatch is for people who got stuck with the problem - it broke rpm, so you needed a special workaround to get out of it
Apr 15 09:19:23 <f13>	yeah, i'm about 3 months behind
Apr 15 09:19:36 <f13>	adamw: I didn't know that, I never hit the issue
Apr 15 09:19:47 <wwoods>	it was x86_64 only or something, right?
Apr 15 09:19:48 <jlaska>	http://rawhidewatch.wordpress.com/2009/04/08/rawhide-x86_64-firefox-and-rpm-broke-workaround-procedure/
Apr 15 09:20:17 <adamw>	yeah - basically it was x86-64 only and only happened if you happened to have packages installed in such a combination that the i586 package would get installed to satisfy a dep that should have been x86-64 only
Apr 15 09:20:24 <adamw>	anyhow, it's all spelled out there so no need to go into details :)
Apr 15 09:20:36 <--	John5342 has quit (Remote closed the connection)
Apr 15 09:20:51 <jlaska>	adamw: thanks for following through, any other comments on that?
Apr 15 09:21:03 <adamw>	nope, nothing springs to mind
Apr 15 09:21:09 <jlaska>	okay
Apr 15 09:21:14 <adamw>	just keep an eye out to do the same thing in future
Apr 15 09:21:32 <adamw>	where there's an important rawhide issue that crops up on test-list or devel-list, just make sure we get a note into rhw
Apr 15 09:22:26 <wwoods>	in the future we should talk about having a special set of bookmarks for rawhide - include rawhidewatch, test day listings, etc.
Apr 15 09:22:27 -->	moixs (n=chatzill@81.13.143.9) has joined #fedora-meeting
Apr 15 09:22:34 <wwoods>	not just on the live images
Apr 15 09:22:46 <f13>	problem is that there can currently only be one bookmarks package
Apr 15 09:22:52 <f13>	we really need there to be multiple
Apr 15 09:23:02 *	jlaska has a highlander flashback
Apr 15 09:23:33 <wwoods>	well, we could just have a package that provides an extra menu full of tester-specific stuff
Apr 15 09:23:43 <wwoods>	including web links and such
Apr 15 09:24:39 <jlaska>	wwoods: not a bad idea if we can figure out a way to wedge it in
Apr 15 09:24:46 <jlaska>	I've added that to open-discussion
Apr 15 09:25:17 <wwoods>	it's a good idea, but as always: we don't need more good ideas, we need code
Apr 15 09:25:17 -->	warren (n=warren@redhat/wombat/warren) has joined #fedora-meeting
Apr 15 09:25:19 <jlaska>	that does touch on the handy qa bookmarks for the test day live images topic too ... so I'm interested in figuring something out there
Apr 15 09:25:40 <jlaska>	okay ... these next 2 topics related to what I was hoping we could spend some brain cycles on today
Apr 15 09:25:45 <jlaska>	# [jlaska] - talk to poelcat about adding a few F11Blocker review meetings to the schedule
Apr 15 09:26:13 <jlaska>	I spoke to poelcat and we do have blocker review days in the schedule (see item#39 in http://poelstra.fedorapeople.org/schedules/f-11/f-11-releng-tasks.html)
Apr 15 09:26:24 <jlaska>	I'll come back to this shortly
Apr 15 09:26:45 <jlaska>	adamw: you have a similar item ... you can update here or we can hold off for the general bug review part?
Apr 15 09:26:48 <jlaska>	# [adamw] - review Test Day X11 bugs to ensure they are represented on F11Blocker
Apr 15 09:26:51 <jlaska>	adamw: you're call?
Apr 15 09:27:22 <adamw>	let's see - I was looking at nouveau bugs, then checked in with darktama and he says he's already doing a review of all of them himself
Apr 15 09:27:25 <adamw>	so that should be covered
Apr 15 09:27:44 <adamw>	radeon and intel I will talk to matej and francois about
Apr 15 09:27:59 <adamw>	stick that down as an action item for me for next week?
Apr 15 09:28:10 *	jlaska sticks
Apr 15 09:28:22 <adamw>	i am a bit worried about radeon, there are rather a lot of open reports on it, several looking quite serious
Apr 15 09:28:27 <adamw>	so i'll definitely want to go through those
Apr 15 09:28:38 -->	cyberpear (n=james@fedora/cyberpear) has joined #fedora-meeting
Apr 15 09:29:41 <jlaska>	adamw: okay I've noted that for next week ... along with radeon concerns
Apr 15 09:29:50 <jlaska>	adamw: any other updates on your end?
Apr 15 09:30:10 <adamw>	er, on what exactly?
Apr 15 09:30:13 <wwoods>	i8xx still seems problematic
Apr 15 09:30:21 <jlaska>	adamw: on the X11 bug front
Apr 15 09:30:22 <adamw>	ah
Apr 15 09:30:38 <adamw>	intel...i haven't looked at the list of intel bugs yet, but my perception is it's not as bad as radeon
Apr 15 09:30:43 <adamw>	and nouveau is working out surprisingly well
Apr 15 09:30:54 <adamw>	radeon seems to be in the worst shape
Apr 15 09:31:11 *	jlaska feels the radeon pain
Apr 15 09:31:39 <wwoods>	radeon is the oldest and arguably the most complex - both the variety of hardware supported by the driver and the complexity of the hardware itself
Apr 15 09:31:46 <wwoods>	it's a toughie.
Apr 15 09:31:56 <wwoods>	luckily I have no radeon hardware at all. ha ha ha!
Apr 15 09:31:57 <jlaska>	wwoods: i8xx ... sorry I'm not familiar, is that the pulse/alsa bug tracking you've been working on?
Apr 15 09:31:59 <--	kital has quit (Remote closed the connection)
Apr 15 09:32:00 <adamw>	so yeah, i'll definitely get those reviewed along with matej and francois
Apr 15 09:32:07 <adamw>	jlaska: he just means intel, i think
Apr 15 09:32:12 <jlaska>	ah okay, sorry
Apr 15 09:32:13 <wwoods>	jlaska: no, intel i8xx series (pre-i915)
Apr 15 09:32:21 *	jlaska shows his X11 rustiness
Apr 15 09:32:24 -->	kital (n=Joerg_Si@fedora/kital) has joined #fedora-meeting
Apr 15 09:32:29 <adamw>	and yeah, as will says, those chipsets are the most problematic for intel
Apr 15 09:32:37 <adamw>	as they had a somewhat different architecture to the newer ones
Apr 15 09:32:44 -->	GeroldKa (n=GeroldKa@fedora/geroldka) has joined #fedora-meeting
Apr 15 09:32:50 <jlaska>	okay ... any other updates from last week?
Apr 15 09:32:54 <wwoods>	see e.g. 490366
Apr 15 09:32:55 <adamw>	so they tend to be a bit buggier than the newer ones (as well as being severely limited in some areas)
Apr 15 09:34:05 <adamw>	but yeah, i need to sit down and go through the intel and radeon open bug lists to have a proper view, so i'll do that for sure.
Apr 15 09:34:48 <jlaska>	wwoods: I don't have a spot in the agenda to talk about your pulsa/alsa efforts, but I know you've been spending some time on that.  Did you want to give an update there?
Apr 15 09:34:56 <jlaska>	s/pulsa/pulse/
Apr 15 09:35:05 <--	cassmodiah has quit ("שָׁלוֹם")
Apr 15 09:35:17 <wwoods>	er, sure
Apr 15 09:36:10 <--	kital has quit (Remote closed the connection)
Apr 15 09:36:12 <wwoods>	basically: pulseaudio has gotten a bad reputation because of broken ALSA drivers and misbehaving applications
Apr 15 09:36:23 -->	pingou_ (n=Pingou@fedora/pingou) has joined #fedora-meeting
Apr 15 09:36:32 -->	kital (n=Joerg_Si@fedora/kital) has joined #fedora-meeting
Apr 15 09:36:36 <wwoods>	most of the latter has been fixed, but a bunch of audio drivers were still broken - notably intel8x0 and intel-hda
Apr 15 09:36:41 <wwoods>	which are amazingly common
Apr 15 09:36:56 <adamw>	they're the most common audio chipsets by a rather wide margin
Apr 15 09:37:01 -->	k0k (n=k0k@fedora/k0k) has joined #fedora-meeting
Apr 15 09:37:09 <adamw>	basically all onboard audio from the last 3-4 years is 99% likely to be one or the other
Apr 15 09:37:25 <wwoods>	http://pulseaudio.org/wiki/BrokenSoundDrivers
Apr 15 09:37:26 *	jlaska ponders another smolt possibility
Apr 15 09:37:44 <wwoods>	people blame pulseaudio a lot, "uninstall pulseaudio" is the common "workaround"
Apr 15 09:37:52 <wwoods>	vitrolic blog posts, etc. etc.
Apr 15 09:38:13 <wwoods>	also it happens that my workstation has one of these chipsets and I can't listen to music anymore. boo!
Apr 15 09:38:34 <wwoods>	so I've spent a couple weeks digging hard into pulseaudio and alsa-lib and kernel sources to try to get to the root of the problem
Apr 15 09:38:35 <jlaska>	heh, that's a motivator
Apr 15 09:38:55 <wwoods>	bug 472339
Apr 15 09:38:57 <buggbot>	Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=472339 medium, medium, ---, kernel-maint, ASSIGNED, snd-intel8x0: timing unstable (snd_pcm_avail() overflows, signals POLLOUT when it shouldn't)
Apr 15 09:39:09 <wwoods>	and bug 485734
Apr 15 09:39:10 <buggbot>	Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=485734 low, low, ---, kernel-maint, MODIFIED, intel-hda: snd_pcm_avail() overflows
Apr 15 09:39:16 <wwoods>	are the main bugs - both on F11Blocker
Apr 15 09:39:46 <f13>	how confident are we that this will get "fixed" for F11?
Apr 15 09:39:46 <jlaska>	nice ... not that there are bugs, but that you have helped narrow it down
Apr 15 09:39:48 <wwoods>	to make a long story short - working with Lennart (PA author) and Jaroslav (kernel sound maintainer) we've determined
Apr 15 09:39:58 <wwoods>	a) PulseAudio is *not* at fault
Apr 15 09:40:30 <wwoods>	b) Intel sound hardware sometimes is flaky about reporting certain bits about its internal state
Apr 15 09:40:55 <adamw>	f13: if it's only glitch-free mode at issue, we have a fairly bulletproof last line of defence: just disable it on the problematic hardware
Apr 15 09:41:04 <adamw>	that at least can be done without too much trouble
Apr 15 09:41:34 <adamw>	if proper fixes to the drivers can't be done in time
Apr 15 09:41:50 <wwoods>	https://bugzilla.redhat.com/show_bug.cgi?id=485734#c16 (reference for a))
Apr 15 09:41:52 <buggbot>	Bug 485734: low, low, ---, kernel-maint, MODIFIED, intel-hda: snd_pcm_avail() overflows
Apr 15 09:42:02 <wwoods>	anyway, a bunch of fixes landed in the upstream alsa kernel
Apr 15 09:42:10 <wwoods>	as of kernel -70 it should be fixed for a majority of cases
Apr 15 09:42:36 *	jlaska queues up a "test"
Apr 15 09:42:48 -->	denise (n=ddumas@66.187.234.199) has joined #fedora-meeting
Apr 15 09:42:51 <wwoods>	we're working on some of the remaining cases - intel8x0 where the clock speed is being detected wrong
Apr 15 09:43:13 <jlaska>	wwoods: thanks for the update ... that's what I was going to ask ... any items you wanted to chase down for next week?
Apr 15 09:43:16 <wwoods>	http://git.alsa-project.org/?p=alsa-kernel.git;a=summary
Apr 15 09:43:35 <wwoods>	the patches starting after 2.6.30-rc1 are the result of this work
Apr 15 09:43:47 <wwoods>	the first two are in our kernel -70, I'm testing the other 4 now
Apr 15 09:43:51 *	jlaska notes the -70 kernel already passes the previous failure scenario (> 30sec of sound)
Apr 15 09:44:04 <wwoods>	there are some positive reports in the bugs about kernel -70
Apr 15 09:44:18 <wwoods>	audio works better on my workstation than it has since F9
Apr 15 09:44:38 <wwoods>	really hoping we can finally put this "just uninstall pulseaudio" nonsense behind us
Apr 15 09:44:55 -->	cassmodiah (n=cass@fedora/cassmodiah) has joined #fedora-meeting
Apr 15 09:45:22 <wwoods>	if it wasn't so late in the game I'd recommend a test day for intel sound hardware
Apr 15 09:45:28 <--	kital has quit (Remote closed the connection)
Apr 15 09:45:38 -->	kital (n=Joerg_Si@fedora/kital) has joined #fedora-meeting
Apr 15 09:45:46 <adamw>	yeah, i was going to say that, but we just don't really have the time, i don't think :\
Apr 15 09:45:47 <jlaska>	yeah I'd love one ... if a slot frees up perhaps we can figure something out
Apr 15 09:45:49 <adamw>	*checks schedule*
Apr 15 09:46:06 *	jlaska hasn't updated 05-14 with iBus yet
Apr 15 09:46:13 <wwoods>	there's enough people CCd on those bugs that I'm fairly confident it's being well tested
Apr 15 09:46:26 <--	balor has quit (Read error: 110 (Connection timed out))
Apr 15 09:46:30 <adamw>	there's a potential slot april 28th or 29th, pretty late though
Apr 15 09:47:17 <adamw>	what do you guys think? worth doing then, or not?
Apr 15 09:47:30 <wwoods>	nah, too late
Apr 15 09:47:42 <wwoods>	the hardware is so common and the test case is so simple
Apr 15 09:48:06 <jlaska>	wwoods: perhaps if we keep a brief check-in for the next few meetings ... sounds like this is something you're actively engaged in already
Apr 15 09:48:07 <wwoods>	I think we can just ask that people try to, y'know, play some music and make sure it works
Apr 15 09:48:42 <adamw>	ok, sounds good
Apr 15 09:48:53 <adamw>	i'll maybe post a quick thread on fedoraforums to see who's having trouble there
Apr 15 09:49:19 <jlaska>	that's a good idea
Apr 15 09:49:29 ---	jlaska has changed the topic to: Fedora Quality Assurance Meeting | autoqa update
Apr 15 09:49:43 <adamw>	stick it down as an action item for me so i don't forget?
Apr 15 09:50:04 <jlaska>	wwoods: I've got autoqa as a rolling topic each week, but I know as we get close to GA finding cycles is tough
Apr 15 09:50:11 <jlaska>	adamw: thx, got it
Apr 15 09:52:03 <jlaska>	wwoods: do you think it's reasonable to have some basic email notification of existing tests to autoqa-results-list before GA?
Apr 15 09:52:12 <--	cassmodiah has quit ("שָׁלוֹם")
Apr 15 09:52:22 *	jlaska thinking of repoclosure or similar test
Apr 15 09:52:40 -->	fraggle_laptop (n=fraggle@aix.steria.org) has joined #fedora-meeting
Apr 15 09:52:41 <f13>	the test itself needs a bit of work
Apr 15 09:53:44 <jlaska>	f13: what sort of work?
Apr 15 09:54:12 <--	EvilBob has quit (Remote closed the connection)
Apr 15 09:54:37 *	jlaska looks at https://fedorahosted.org/pipermail/autoqa-results/2009-April/000000.html
Apr 15 09:55:06 <jlaska>	okay, we can come back to this if there are no updates ... I want to save time for F-11 Blocker discussion
Apr 15 09:55:06 <--	johe has quit (Read error: 104 (Connection reset by peer))
Apr 15 09:55:14 -->	ankit (n=ankit@117.195.96.93) has joined #fedora-meeting
Apr 15 09:55:58 <--	lfoppiano has quit (Read error: 113 (No route to host))
Apr 15 09:56:29 <jlaska>	I'll sync up with wwoods to see if the current 'next steps' are still accurate (https://fedoraproject.org/wiki/QA/Meetings/20090408#Autoqa_update)
Apr 15 09:56:29 <f13>	sorry
Apr 15 09:56:39 <f13>	the test itself "passes" even if there are broken deps
Apr 15 09:56:51 <f13>	and it has some interesting issues with how it's being ran with temp cache data, and arch settings
Apr 15 09:56:55 -->	Bouska (n=Pablo@ip-213-49-225-184.dsl.scarlet.be) has joined #fedora-meeting
Apr 15 09:57:11 <wwoods>	sorry, problems on my machine
Apr 15 09:57:56 <jlaska>	no worries
Apr 15 09:58:44 <jlaska>	I don't mind so much if the repoclosure test still needs massaging, I think just seeing that the "tests" are automatically running and sending output somewhere
Apr 15 09:59:07 <wwoods>	f13: can you tell me more about the "interesting issues"? we can work on fixing that
Apr 15 09:59:15 <wwoods>	returning a useful result is pretty easy to fix
Apr 15 09:59:24 <wwoods>	but I'm not sure about the other stuff
Apr 15 09:59:50 <f13>	I think we need to make it use a temp cache dir for the repodata
Apr 15 10:00:03 -->	tatica (n=tatica@nelug/designer/tatica) has joined #fedora-meeting
Apr 15 10:00:05 <f13>	but I need to run it through again to see the output
Apr 15 10:00:21 <jlaska>	wwoods: f13: are you guys up for meeting later this week to hash through any issues on autoqa?
Apr 15 10:00:23 <wwoods>	okay
Apr 15 10:00:30 <wwoods>	jlaska: yeah, that'd be great
Apr 15 10:00:32 <jlaska>	I can setup a time to chat etc...
Apr 15 10:00:52 <f13>	yeah... it's going to be busy this week, but sure
Apr 15 10:01:03 *	jlaska TODO's
Apr 15 10:01:27 ---	jlaska has changed the topic to: Fedora Quality Assurance Meeting | F-11 Blocker Bugs
Apr 15 10:02:03 <jlaska>	I was hoping to spend some time today discussing ways we can invite help from others for assessing blocker bug status
Apr 15 10:02:15 <jlaska>	we've talked about this in the past, and it's tough issue
Apr 15 10:03:00 <jlaska>	wwoods and I were discussing this week and we both mentioned that much of the decision about whether something shoudl be on the blocker list is a 'gut' feel based on experience
Apr 15 10:03:25 <adamw>	i've been trying to ask bugzappers to flag up bugs in their particular components as blockers, but getting some resistance as they feel they might not do it right
Apr 15 10:03:47 <f13>	yay!  new glibc building which should fix mysql (and emacs?)
Apr 15 10:03:52 <wwoods>	expanding and clarifying releasecriteria (or having separate blockercriteria) might be a good idea
Apr 15 10:03:53 <jlaska>	I can't help but feel we can describe a bit of that 'gut' feel in an effort to solicit help from others for assessing blocker bugs
Apr 15 10:04:02 <adamw>	jlaska pointed to the wiki page to be used as a reference, but everyone felt it was a bit below scratch
Apr 15 10:04:05 -->	Sparks (n=Sparks@fedora/Sparks) has joined #fedora-meeting
Apr 15 10:04:14 <jlaska>	wwoods: yeah you've got a great start alread on th release criteria page https://fedoraproject.org/wiki/QA/ReleaseCriteria
Apr 15 10:04:34 <wwoods>	there's some fairly well-defined ways to evaluate stuff - severe bugs in Important Apps, any data corruptor in any package
Apr 15 10:04:36 <jlaska>	adamw: cbeland has the priority/severity draft - http://fedoraproject.org/wiki/User:Beland/Bugzilla_Legend#Severity_and_Priority
Apr 15 10:04:56 <wwoods>	severe bugs in firefox might be a blocker, while severe bugs in frozenbubble generally wouldn't
Apr 15 10:05:03 <wwoods>	except IIRC that's not on the release criteria
Apr 15 10:05:39 <jlaska>	are the QA release criteria and the evaluation of blocker bugs the same things?
Apr 15 10:05:57 <jlaska>	I feel like one is definitely a QA decision/result
Apr 15 10:06:12 <adamw>	wwoods: that's basically my take on 'priority' and 'severity', to rehash it for the tenth time :)
Apr 15 10:06:18 <jlaska>	while the perhaps the blocker bugs should be more based on data (aka the severity listed by cbeland)
Apr 15 10:06:30 <jlaska>	adamw: what's your take?
Apr 15 10:06:33 <adamw>	just a sec while i read what beland wrote
Apr 15 10:06:43 <--	londo has quit (Remote closed the connection)
Apr 15 10:06:53 <adamw>	ah, he basically went with my system
Apr 15 10:06:57 -->	londo (n=georgiou@82.133.49.59) has joined #fedora-meeting
Apr 15 10:07:00 <jlaska>	here? http://fedoraproject.org/wiki/User:Beland/Bugzilla_Legend#Severity_and_Priority
Apr 15 10:07:02 <adamw>	in which case, yes, priority is something of an overlap with blocker bugs
Apr 15 10:07:59 <adamw>	but they're not really the same
Apr 15 10:08:07 <jlaska>	adamw: what severity and priority?
Apr 15 10:08:15 <adamw>	jlaska: on that page
Apr 15 10:08:24 <adamw>	i mean, priority isn't the same as blocker evaluation
Apr 15 10:08:30 <jlaska>	agreed
Apr 15 10:08:41 <adamw>	first of all, priority is more fine-grained. second of all, it covers bugs in released versions as well as rawhide.
Apr 15 10:09:00 <adamw>	so, uh. sorry. big topic. let me organize :)
Apr 15 10:09:11 <adamw>	i guess if we adopted that system going forward, triage would naturally feed into blocker bug evaluatio
Apr 15 10:09:12 <adamw>	n
Apr 15 10:09:27 <adamw>	because we could simply look at all bugs with priority 'urgent' in rawhide as a step in evaluating blockers
Apr 15 10:09:52 <adamw>	but that draft is still contingent on my poking the developers for feedback, which is on my todo list on the bugzappers side
Apr 15 10:09:53 <f13>	I'm still not convinced that exposing and actually trusting severity/priority in bugs is worthwhile.
Apr 15 10:10:09 <f13>	every person's pet bug is high priority high severity
Apr 15 10:10:23 <adamw>	f13: i think we should at least try it, and if it turns out to be train wreck, we can stop again. but as i've mentioned, i've generally found that once it's been set by a triager, most reporters respect that
Apr 15 10:10:32 <f13>	if we didn't let the reporter frob that knob it would be different.
Apr 15 10:10:46 <adamw>	yeah, that's certainly a possibility if it turns out to be a problem - but maybe it won't.
Apr 15 10:10:52 <f13>	adamw: well, it has been a train wreck in Red Hat land up to the point where most maintainers just flat out ignore it
Apr 15 10:10:59 <adamw>	f13: because it's being set by reporters
Apr 15 10:11:00 <jlaska>	I agree ... we need to invite others to help with this ... my concern is it's too much for a small group of folks to maintain
Apr 15 10:11:11 <adamw>	who obviously can't do it right because we don't have any kind of policy or guidelines on what the hell they mean
Apr 15 10:11:22 <jlaska>	and if we want help from others, we need to provide some breadcrums/guidance
Apr 15 10:11:25 <f13>	adamw: and when it was adjusted by the maintainer the reporter puts it back, and you get a revert war
Apr 15 10:11:27 <wwoods>	the entire blocker-bug system is kind of a workaround for the fact that users can (and do) set priority capriciously
Apr 15 10:11:42 <f13>	so most of us are trained to simply ignore what the reporter puts it at all together and avoid the needless battle
Apr 15 10:11:52 <adamw>	f13: as i said, that's just not been my experience - only a handful of reporters get into revision wars
Apr 15 10:12:02 <adamw>	but anyhoo
Apr 15 10:12:07 <adamw>	my proposal is, let's try it and see what happens
Apr 15 10:12:07 -->	johe (n=jstephan@p5B3239FA.dip.t-dialin.net) has joined #fedora-meeting
Apr 15 10:12:08 <f13>	perhaps mdv's users are different from Fedoras (:
Apr 15 10:12:12 <adamw>	it can't hurt anything really
Apr 15 10:12:24 <adamw>	it's not like we can wield a big stick and force maintainers to respect those settings
Apr 15 10:12:28 <adamw>	if they want to ignore them, they will
Apr 15 10:12:29 <f13>	I'm all for trying, but don't expect maintainers to actually care about severity/priority settings
Apr 15 10:12:39 <wwoods>	the whole system would be simpler if we just had a "release blocker" priority, but it doesn't work quite right
Apr 15 10:12:47 <adamw>	i'm hoping that if it succeeds, they will *want* to, because the whole point is it helps maintainers
Apr 15 10:12:49 <f13>	what would you consider "success" in  your trials?
Apr 15 10:13:06 <adamw>	no revert wars, positive feedback from maintainers looking at their bug lists
Apr 15 10:13:23 <jlaska>	community participation in the escalation of blocker bugs
Apr 15 10:13:27 <adamw>	yes
Apr 15 10:13:39 <f13>	I often wonder how many maintainers actually look at their bug list directly, as opposed to filtered through something like F11Blocker et al
Apr 15 10:13:40 <jlaska>	there are going to be some pain points I'm sure
Apr 15 10:13:44 <adamw>	if we *do* get problems with revert wars, then we look at how to fix that, if we can't, we dump the system and just hide the damn fields
Apr 15 10:13:47 <f13>	(or bugs with certain flags on them internally)
Apr 15 10:14:23 <adamw>	f13: i'd be distinctly worried about any maintainer who didn't care about any bug in his package that wasn't listed as a blocker. that really shouldn't happen.
Apr 15 10:14:34 <f13>	I would suggest you come up with the plan of how to use them, and what measurements you will use to determine success/failure and pitch it to FESCo as an F12 experiment
Apr 15 10:14:51 <adamw>	if you're maintaining a package you should be able to be vaguely on top of the bug list for it. even if on top of means closing trivial bugs with a comment saying you don't have time to fix 'em.
Apr 15 10:14:55 <jlaska>	f13: I'm looking for a solution to help manage the F11Blocker list
Apr 15 10:14:55 <f13>	adamw: when you've got a bug list that is hundreds long, you only have time to worry about the things that are blockers
Apr 15 10:15:03 <viking_ice>	joins late in the game no point using or changing priority on report I thought everybody knew that maintainers dont give a frack about the severity/priority on reports?
Apr 15 10:15:14 <f13>	closing trivial bugs isn't the right thing to do, closing it doesn't make the bug go away
Apr 15 10:15:15 <adamw>	viking_ice: the reason they don't is that it's never set usefully
Apr 15 10:15:30 <adamw>	viking_ice: the point of the enterprise is to have them set usefully so it will actually be helpful to maintainers to care about them
Apr 15 10:15:39 <f13>	jlaska: define "manage"
Apr 15 10:15:43 <wwoods>	it's a cycle. the fields are ignored because they're useless, and they're useless because they're ignored
Apr 15 10:15:45 <jlaska>	that's a good point ... at this point I'm not so interested on whether these values serve as a priority for development
Apr 15 10:15:55 <jlaska>	to me, that's later down the road
Apr 15 10:16:00 <viking_ice>	adamw: wrong the reason is they them self are the only once that can judge where on their priority list the bug is
Apr 15 10:16:10 <viking_ice>	s/once/one
Apr 15 10:16:13 <adamw>	remember, I've *been* a package maintainer, and I was a lot happier when I could work on my bug list from critical down to trivial rather than having to try and figure it out myself or just take them in numerical order
Apr 15 10:16:29 <viking_ice>	Then you must have been the only one..
Apr 15 10:16:46 <jlaska>	f13: I'd like to see that all the items on the blocker list pass some agreed criteria for being on there
Apr 15 10:16:52 <adamw>	viking_ice: not in my experience. i've been in the position of maintaining several dozen packages at once and i found the judgment of experienced triagers very useful, if i'd spent all my time trying to prioritise the bugs i'd never have had time to fix any of them.
Apr 15 10:16:54 <f13>	the nature of Fedora right now is that there are far more bugs than people to work on them, regardless of priority/severity
Apr 15 10:17:04 <jlaska>	f13: agreed ... and that's okay
Apr 15 10:17:06 <f13>	and Fedora is a serve yourself world, where maintainers of the packages get to choose what they want to work on
Apr 15 10:17:25 <adamw>	sure. i'm not planning anything to try that
Apr 15 10:17:28 <adamw>	s/try/change/
Apr 15 10:17:28 <f13>	some groups, such as QA  and releng, can offer suggestions of what is more important to fix, with the various trackers/blockers
Apr 15 10:17:34 <adamw>	just provide more useful input
Apr 15 10:17:37 <viking_ice>	adamw: being both the maintainer and the developer on the application?
Apr 15 10:18:00 <adamw>	there's a logical problem here: the thrust of your arguments appears to be "there's no point bothering about bug priority because maintainers will only work on what they want to", in which case, why do we have a blocker list?
Apr 15 10:18:03 <f13>	adamw: as long as you pitch it that way I think you'll find much less push back
Apr 15 10:18:03 <jlaska>	f13: that's a good point.  Getting something off the blocker list doesn't mean it has to be fixed ... it can be release noted, or just ignored (which hurts everyone)
Apr 15 10:18:25 <f13>	adamw: always gear it towards "informative" rather than declarative
Apr 15 10:18:32 <adamw>	f13: that's what i've been saying all along
Apr 15 10:18:39 <adamw>	i'm not sure why you think i'm not
Apr 15 10:18:51 <f13>	adamw: the first instinct of many people will be to think that QA will want to force what people will work on
Apr 15 10:18:51 <adamw>	i already *said* there's no way we can force anyone to care about the fields, all we can do is provide them
Apr 15 10:19:01 <f13>	mostly because QA/PM does that in RHEL
Apr 15 10:19:10 <adamw>	well, that's not the idea at all.
Apr 15 10:19:11 <jlaska>	f13: that's not right entirely there
Apr 15 10:19:16 <jlaska>	f13: we just provide the data
Apr 15 10:19:21 <f13>	not only force what you should be working on but prevent working on anything else
Apr 15 10:19:29 <f13>	jlaska: qa ack?
Apr 15 10:19:35 <f13>	without it nothing can be worked on
Apr 15 10:19:41 <jlaska>	f13: there's 3 parts to that ack
Apr 15 10:19:44 <f13>	sure
Apr 15 10:19:45 <jlaska>	and ther'es the schedule
Apr 15 10:19:52 <jlaska>	so qa ack is no guarruntee
Apr 15 10:19:58 <jlaska>	it's just a way of getting it on the Blocker list
Apr 15 10:20:02 <jlaska>	much the same way we do now
Apr 15 10:20:04 <f13>	but at the end of the day, people besides the developer force what is worked on
Apr 15 10:20:10 <f13>	in RHEL
Apr 15 10:20:11 <jlaska>	and "fixing" could mean code, documentation / release note
Apr 15 10:20:11 -->	VanRoy (n=vanroy@mna75-2-82-67-196-165.fbx.proxad.net) has joined #fedora-meeting
Apr 15 10:20:29 <f13>	that's going to be the immediate assumption/fear around anything remotely close to that in Fedora land
Apr 15 10:20:32 <--	kital has quit (Success)
Apr 15 10:20:32 <f13>	its a touchy subject
Apr 15 10:20:39 <jlaska>	definitely
Apr 15 10:20:49 <jlaska>	so certainly something we need to be careful in messaging
Apr 15 10:20:54 <adamw>	anyhow, we're spinning wheels - point is, we're working on this, it's advisory, if it works great if it doesn't we'll kick it to the curb, and we can evaluate down the road how severity/priority and blocker lists are/should be interacting
Apr 15 10:21:05 <f13>	I've always tried very hard to let the maintainers do what they think best in Fedora.  Triage and setting of priority/severity can certainly help the maintainer make that decision, so long as they have the ultimate say
Apr 15 10:21:44 <adamw>	i'll make sure to make that very clear in the proposal, then. i'm going to send a draft to test-list of the mail i will eventually send to devel-list, so you'll be able to see it and provide feedback at that stage
Apr 15 10:21:56 <f13>	cool
Apr 15 10:22:00 <--	jnettlet has quit (Remote closed the connection)
Apr 15 10:22:45 <adamw>	one concrete thing that occurs is we can make it a rule for triagers not to touch priority / severity without the maintainer's permission *if the maintainer already touched it first*
Apr 15 10:22:56 <adamw>	that will cover the case of maintainers who prefer to actively manage those settings themselves
Apr 15 10:23:23 <jlaska>	and we can always reach out to solicit a maintainer group to join a "pilot"
Apr 15 10:23:45 <adamw>	yes - well, basically it would be a group to provide active feedback
Apr 15 10:24:03 <adamw>	i.e. see if there are people who are willing to take a periodic look at their bug list ordered by severity/priority and see if it's useful to them
Apr 15 10:24:22 <viking_ice>	this will never work..
Apr 15 10:24:30 <adamw>	oh, quit being pessimistic :)
Apr 15 10:24:40 <jlaska>	adamw: do you have any thoughts on how this can be used to guide blocker bug input?
Apr 15 10:25:15 <adamw>	i mentioned that way up above :) basically i'd say the obvious thing initially would be to use a search on 'urgent' priority bugs in rawhide as an input to the blocker list
Apr 15 10:25:29 <jlaska>	sorry yes you did
Apr 15 10:26:18 <jlaska>	yeah that seems sensible (to me)
Apr 15 10:26:23 <adamw>	ok
Apr 15 10:26:40 <adamw>	still, it depends on the system working out, and triage covering a sufficient mass of bugs, so we'll have to see how those pan out
Apr 15 10:26:43 <jlaska>	I suspect we're not going to be able to build a ruleset that applies to 100% of the bugs
Apr 15 10:26:58 <f13>	priming the blocker list will never be a single data point
Apr 15 10:27:06 <adamw>	no, but that's generally true for triage - it's very hard to write out a prescriptive list of everything
Apr 15 10:27:14 <jlaska>	but if we can have something that helps manage the 80% or higher ... it's worth trying imo
Apr 15 10:27:31 <adamw>	i think the guidelines on that draft page are a good start, and further to that we can take things as they arise
Apr 15 10:27:35 <f13>	whatever helps us or maintainers find the critical issues sooner rather than later will help
Apr 15 10:27:40 <adamw>	right
Apr 15 10:27:44 <jlaska>	exactly
Apr 15 10:28:00 <adamw>	so, this is a medium-term thing: to go back to the initial discussion, in the short term, how do we broaden input into the blocker lists without losing signal?
Apr 15 10:28:24 <adamw>	to take a concrete example, do we want bugzappers to contribute to the list, and if so how can we help them do it productively?
Apr 15 10:29:00 <wwoods>	We almost never drop anything from Target
Apr 15 10:29:14 <wwoods>	we can encourage people to 'nominate' bugs by adding them to Target
Apr 15 10:29:20 <wwoods>	and then cherry-pick from Target to Blocker
Apr 15 10:29:22 <adamw>	do we have a feel for how effective Target is, though? i kinda get the feeling it may be a bit of a dumping ground
Apr 15 10:29:41 <f13>	wwoods: I don't know if that will scale
Apr 15 10:29:43 <wwoods>	It is indeed a bit of a dumping ground
Apr 15 10:29:51 <f13>	wwoods: often Target is too huge to get through for any one person
Apr 15 10:30:13 <f13>	my thought has always been that Target is useful for the individual maintainer who's bug gets put on it
Apr 15 10:30:18 <adamw>	we could have a meeting, split it up into chunks, give each person a chunk to go through and flag up candidates for group discussion, i guess...
Apr 15 10:30:25 <f13>	but Target isn't wholly managed by any group or entity
Apr 15 10:30:32 <jlaska>	hey guys, I'm sorry, I have a hard stop here
Apr 15 10:30:34 <f13>	Blocker gets much more attention and pruning
Apr 15 10:30:38 <adamw>	f13: do you get a feeling that bugs added to Target get fixed with more urgency? i.e. maintainers find that status useful?
Apr 15 10:30:40 <wwoods>	It could be managed by the bugzappers?
Apr 15 10:30:58 <f13>	adamw: I'd like to think so, but I have no evidence one way or another
Apr 15 10:30:59 <jlaska>	adamw: f13: wwoods: you guys okay with continuing in #fedora-qa  ?
Apr 15 10:31:04 <adamw>	yeah sure
Apr 15 10:31:08 <f13>	adamw: it'd be a good question to ask our maintainers if we're considering changing things.
Apr 15 10:31:11 <f13>	sure
Apr 15 10:31:12 <adamw>	ok, noted
Apr 15 10:31:22 <viking_ice>	it all boils down to developers work load hence he needs to set the severity/priority based on the time he has to work on the report ( which most of them user their own organizing system ) so reporters or triagers changing or setting the severity/priority will have no effect
Apr 15 10:31:35 <jlaska>	thanks folks, sorry we didn't have time to open up for discussion ... please send mail to the list or continue in #fedora-qa