Latest revision as of 20:09, 19 October 2009

Attendees

People present (lines said)

jlaska (174)
wwoods (52)
Oxf13 (52)
adamw (50)
kparal (28)
Viking-Ice (13)
Southern_Gentlem (11)
lili_ (10)
nirik (10)
zodbot (8)
mcepl (3)
buggbot (2)
mbonnet (2)
notting (1)
Jeff_S (1)

Regrets:

He Rui (rhe)

Agenda

Preview Meeting follow-up

QA/Meetings/20091012#Action_items

jlaska will investigate the 5 anaconda F12Beta issues to determine when the failures were introduced

INPRGRESS - Adam Williamson posted feedback during the beta release readiness meeting 36 issues were marked as beta blockers prior to freeze, 16 after the freeze.. I am manually inspecting the bugs added to the blocker list after the freeze (Sept 31) to determine if there is a pattern. So far, only 2 bugs took longer than 2 days to be escalated to the F12Beta blocker list. More manual fiddling required

jlaska to investigate packaging of israwhidebroken.com for production instance

Packaged thanks to python setuptools. Need to determine whether to incorporate into autoqa now. Wwoods had the suggestion of creating a autoqa/front-ends directory to include this and other "Is <component> broken?" front-ends.

jlaska to request autoqa-devel@ for autoqa development discussion and patch review

https://fedorahosted.org/fedora-infrastructure/ticket/1733

Beta test review

Jlaska asked the group for feedback on what worked and what needs improvement for how the team tracks blocker bugs and organizes testing.

Liam suggested on coming up with ways to achieve 100% test execution on the test matrix ^[1]. At least aiming for completion of tier#2 tests in the test plan ^[2]. Southern_Gentlem suggested looking at the spins test matrix ^[3]. Jlaska asked if any optimizations are available in the current test matrix, perhaps removing duplicate testing or removing tests altogether. Lili and Jeff_S entertained whether or not that would mean reduced quality in the end. Jlaska asked if the two test matrices could combine efforts somehow?

Adamw noted that while the results weren't tracked in the wiki matrix, he has the triumvirate of video adapters (radeon, nvidia and intel). Each adapters was verified against the beta. As for the test matrix, Adam suggested it can be overwhelming at first. Perhaps re-ordering the links such that the UNTESTED cells are at the top of the page? Jlaska came back to reality after thinking about a possible crowd-sourcing option for gathering install use case feedback from testers.

This initiated a brief discussion by Oxf13 about a formal test case management system (TCMS). Jlaska suggested that a TCMS isn't something we'd really want or need in QA at this time. Adam added, yes, if only we had a TCMS we could spend lots of time maintaining and debugging it instead of testing things! Jlaska concluded by adding, I'm really not convinced that a TCMS created and maintained by this small group is the way to improving quality in Fedora.

Summary of recommendations:

integration between lili and Southern_Gentlem's test matrices
making it easier to see what testing remains in lili's test matrix

AutoQA Updates from wwoods and kparal

Wwoods and kparal provided updates on autoqa progress.

we're still working on getting the production autoqa instance active
- Hardware shipment to PHX2 still inprogress
- More packaging work needed to integrate israwhidebroken.com
I've given up on patching autotest to add info about the job ID to the tests as they run. far simpler just to write a small "how to find test results" document rather than maintaining an invasive and complicated patch
A draft koji hook/watch has been pushed to git (see https://fedorahosted.org/autoqa/browser/hooks/post-koji-build/watch-koji-builds.py). it works basically like the other watchers, listing all new builds since the previous run. Next step is to define what any koji-watcher test would need as arguments/requirements. From there, we can complete the hook.

rpmguard

Kparal provided updates on the packagediff/rpmguard front:

name: the script for displaying important differences between rpms, originally called 'packagediff', was renamed to 'rpmguard'
location: the autoqa project has provided hosting for the rpmguard (see http://git.fedorahosted.org/git/autoqa.git?a=tree;f=tests/rpmguard)
Kparal noted he has several test packages built using rpmfluff to test rpmguard functionality. So far so good, but he welcomes any community testing.

Kparal asked for community feedback on 2 aspects of rpmguard:

testing - I will be very glad if you download it, try it, provide a feedback on it. But please be sure also to use latest rpmdiff from svn (prerequisite for rpmguard), because there were some important bugs fixed recently. I will also write a blogpost and post a message to mailing lists in the next days.
output - Also, if you have some suggestions how to restructure the output of rpmguard, to be better parseable/machine processable, let me know. Especially if wwoods have some requirements what to ouput so that autoqa can utilize it, I'm all ears.

How_to_Debug_<component> Update from Viking-Ice

VIking-Ice indicated adamw was looking into testing a new wiki-style Template. Adamw expertly delegated the to rjune's expertise, which resulted in 2 new pages:

Adamw indicated that we should be able to come up with a template which defines the general layout in a flexible enough way that we can still customize individual pages. However, some additional work is needed. If we cannot produce a page in a reasonable time frame, we will continue manual wiki edits.

Adamw asked if someone would like to rename the existing Category:Debugging pages to use the new format: How to debug <component> problems. Adamw also suggested changing the back-links to avoid double redirect issues on the wiki. Jlaska agreed to rename the pages.

Open floor - <your topic here>

CritPath testing

Oxf13 asked for extra eyes/fingers as crit-path tag requests come in for final.

Adamw asked whether the process for requesting a post-Beta tag was documented. To track crit-path updates, F13 recommended:

subscribe to rel-eng@lists.fedorahosted.org list
monitor RSS feed - https://fedorahosted.org/rel-eng/timeline?ticket=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss (may require URL tweakage)

Jlaska asked if there was a standard set of information tagging requests should include? For example, a link to the F12Blocker bug, a link to the patch(es), and a statement of severity or user impact. F13 advised there is no standard at this time, but we do currently ask:

what they are fixing,
why,
what testing they've done,
and what happens if we don't include it

Jlaska asked if a template exists for this information? F13 noted that the make tag-request process asks for this information. Mcepl provided a link to more details on this process at ReleaseEngineering/FinalFreezePolicy.

Common_F12_Bugs

Adamw reminded the group, if you're aware of any bug that's in the released beta images that you think should be documented there, please either add it (there's guidelines on layout in the wiki page source) or add the 'CommonBugs' keyword to the bug report.

Bugs that need Common_F12_Bugs documentation

rats_install still failing

Jlaska asked if there were any updates on the download.fedora.devel.redhat.com rsync from download.fedoraproject.org. It appears autoqa rats_install results are still failing due to bad content on the download site (see https://fedorahosted.org/pipermail/autoqa-results/2009-October/001654.html).

Still needs investigation.

F-12 Talking Awesomeness talking points

Adamw recommended F12_Beta_Announcement for folks looking for talking points about what's new in Fedora 12.

Upcoming QA events

2009-10-12 - F12 Beta go/no_go meeting (@ 18:00pm - rel-eng meeting)
2009-10-13 - BugZappers/Meetings
2009-10-14 - Beta Project Wide Release Readiness Meeting
2009-10-15 - i18n Test Day

Action items

jlaska to rename other debug pages (see https://fedoraproject.org/wiki/Category:Debugging) to be consistent with "How to debug <component> problems". Update back-links also

IRC transcript

jlaska	#startmeeting Fedora QA Meeting	15:58
zodbot	Meeting started Mon Oct 19 15:58:44 2009 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.	15:58
zodbot	Useful Commands: #action #agreed #halp #info #idea #link #topic.	15:58
jlaska	#topic gathering in the lobby	15:58
* kparal is here		15:58
Southern_Gentlem	.fas jbwillia	15:59
zodbot	Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@yahoo.com> - jbwilliams 'Jason Williams' <jb.williams@tiscali.co.uk>	15:59
jlaska	welcome kparal and Southern_Gentlem	15:59
jlaska	I believe we are joined by lili for the first time today?	15:59
kparal	oh, what's the time for him?	15:59
jlaska	LATE! :)	16:00
kparal	exactly midnight in bejing, if i see right	16:00
lili_	deep night :)	16:00
jlaska	wwoods: adamw: you guys in lurk mode?	16:00
adamw	morningh	16:00
* wwoods lurking, may need to leave early on an errand		16:01
jlaska	adamw: wwoods: howdy gents	16:01
jlaska	we've got a busy agenda today ... so I'm going to just start moving	16:01
jlaska	feel free to stop me or slow me down if there any points missed	16:02
jlaska	and again ... thanks for staying up late and joining us Liam :)	16:02
lili_	I am ok, :)	16:02
jlaska	I'll be walking through the proposed agenda - https://www.redhat.com/archives/fedora-test-list/2009-October/msg00382.html	16:02
jlaska	starting with ...	16:03
jlaska	#topic Previous meeting follow-up	16:03
jlaska	Oxf13 raised some concerns in the last meeting that QA was finding blocker bugs too late after the freeze	16:03
Oxf13	I'm here, sorry having some irc issues	16:04
jlaska	Oxf13: hi there!	16:04
jlaska	adamw has a clever+simple solution to scrubbing the blocker list ... just use the blocker bug history	16:04
jlaska	(instead of a complicated bz boolean search)	16:04
jlaska	#link https://bugzilla.redhat.com/show_activity.cgi?id=507678	16:04
jlaska	if I can quote adamw from the meeting ...	16:05
jlaska	#info "36 issues were marked as beta blockers prior to freeze, 16 after the freeze." -adamw	16:05
jlaska	what I'm trying to find out is if there was significant delay in finding and escalating	16:05
Oxf13	brb	16:05
jlaska	so far, only one bug on the blocker list has more then 2 days between filing and escalating	16:06
jlaska	that's not bad ... imo	16:06
jlaska	I'm still looking, and I'd really like if I could use python-bugzilla to make it easier to perform this query in the future, but for now ... it's manual	16:06
jlaska	bug#523862 was found during the StorageRewrite test day that rhe organized, but not escalated until 10-02 ... that's the only one that looks like we could have escalated sooner had the impact been known	16:07
buggbot	Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=523862 urgent, low, ---, dledford, CLOSED RAWHIDE, mdadm craps at boot	16:07
* Viking-Ice sneaks in from one meeting to another..		16:07
jlaska	so ... summary from me is I'm still looking for a trend that we can address in future testing, but I feel like we covered this well with test days and lili's test runs	16:07
jlaska	Viking-Ice: howdy	16:07
jlaska	#info jlaska manually inspecting F12Beta change history to see if any trends / problems exist in how we escalate blocker bugs	16:08
jlaska	Next up ...	16:08
jlaska	* jlaska to investigate packaging of israwhidebroken.com for production instance	16:08
jlaska	this was really easy, wwoods did the hard work already here	16:08
jlaska	we can talk more about it in the autoqa section, but israwhidebroken.git already uses setuputils	16:09
jlaska	so it was a simple matter of `python setup.py bdist_rpm`	16:09
jlaska	Now I just need to follow through with wwoods idea of adding a "autoqa/front-ends/" directory to house this content	16:09
wwoods	yeah that's easy enough	16:09
jlaska	wwoods: once this next action item gets done ... I'll send updates that route ...	16:10
jlaska	* jlaska to request autoqa-devel@ for autoqa development discussion and patch review	16:10
wwoods	now that we know how to get it packaged/installed properly we make it a subpackage of autoqa if we like	16:10
jlaska	#info autoqa-devel mailing list has been requested - https://fedorahosted.org/fedora-infrastructure/ticket/1733	16:10
jlaska	wwoods: I _definitely_ would appreciate some patch review for anything I touch!	16:10
jlaska	so I'd like to get my changes out to the list for comments/feedback	16:10
jlaska	I usually beg jds2001 for help with creating mailing lists, but if someone knows another contact who can assist on the infrastructure team?	16:11
jlaska	#help New mailing list requested for autoqa development discussion - see https://fedorahosted.org/fedora-infrastructure/ticket/1733	16:11
jlaska	okay ... any other follow-up actions from last week that I missed?	16:12
jlaska	if not ... I'll start with #2 on https://www.redhat.com/archives/fedora-test-list/2009-October/msg00382.html	16:12
jlaska	#topic Beta test review	16:12
jlaska	As we did for the Alpha, I'd like to spend a moment on the Beta	16:13
jlaska	what worked, what didn't, what could be improved	16:13
jlaska	lili_: thank you for sending out the test run summary	16:13
jlaska	#link https://www.redhat.com/archives/fedora-test-list/2009-October/msg00303.html	16:13
jlaska	lili_: do you have any thoughts to share on what worked well, or what you would like to see improved next time?	16:13
lili_	what I am thinking is how to complete the test cases that still did not complete on test results	16:14
jlaska	lili_: so a way to get to 100% executed in the test matrix?	16:15
lili_	some cases have to run on some special hardware, like efi	16:15
jlaska	#info Fedora 12 Beta Install test matrix - https://fedoraproject.org/wiki/Test_Results:Fedora_12_Beta_RC2_Install	16:15
lili_	at least to finish all the tire 2 test cases according to our test plan	16:16
jlaska	lili_: well, on the good news front, if you sort by test priority ... I believe all tier#1 tests are executed. That's a positive!	16:16
Southern_Gentlem	lili_, also look at http://spins.fedoraunity.org/Members/Southern_Gentleman/Fedora%2012%20%20beta%20TestMatrix as well	16:16
jlaska	#info Southern_Gentlem directed the team towards a different test matrix - http://spins.fedoraunity.org/Members/Southern_Gentleman/Fedora%2012%20%20beta%20TestMatrix	16:16
jlaska	lili_: what if we run fewer tests?	16:16
lili_	that will reduce our quality?	16:17
jlaska	excellent question to ask ... I'm not certain of the answer	16:18
Jeff_S	that's quite hard to quantify	16:18
jlaska	obvious, we'd want to make the most efficient use of our testing time, so if there is any duplication ... perhaps that's an area to reduce	16:18
adamw	i should quickly note that, although we didn't put it in the matrix, i did have the Golden Trifecta of video adapters here for the last few weeks (radeon, nvidia, intel) and verified the beta at least basically worked on all three of my test systems.	16:18
jlaska	#info lili asked if reducing the number of test cases would reduce quality	16:19
jlaska	Some ways I can think of getting more complete results in the test matrix is by more testers, automation or reducing the matrix	16:20
jlaska	lili_: have a look at Southern_Gentlem's matrix ... he has some interesting tests	16:20
jlaska	Southern_Gentlem: would you be interested in seeing your tests become wiki test cases that we can both link to and use?	16:20
Southern_Gentlem	fine with me	16:21
jlaska	adamw: you've always been a fan of the installer matrix ... do you have any thoughts on how we can get to a more complete test results into the matrix?	16:21
jlaska	Southern_Gentlem: no sense in us duplicating effort if we can avoid it	16:22
adamw	i think it's pretty overwhelming, but we've discussed before that it's not trivial to reduce it	16:23
adamw	if we could get tricksy we could have a dynamically generated 'not-yet-completed tests' version of the matrix?	16:23
adamw	which only shows the white boxes...	16:23
Oxf13	if only we had a test case management system	16:23
jlaska	not something we want or need	16:24
jlaska	adamw: you can sort the matrix now to get that ... but certainly not as dynamic as you suggest	16:24
adamw	yes, if only we had a TCMS we could spend lots of time maintaining and debugging it instead of testing things!	16:24
jlaska	I keep thinking there's a <buzzword> crowd source </buzzword> solution here if we could gather feedback ... something smolt-like	16:24
jlaska	that's probably too out there and not anything short-term	16:24
Oxf13	adamw: instead of spending time trying to figure out the right magical wiki incantation to get a box to change from white to yellow or red?	16:25
Southern_Gentlem	my test cases have come from testing re-spins which evolved over time	16:25
jlaska	Oxf13: sorry, been there done that. I'm really not convinced that a TCMS created and maintained by this small group is the way to improving quality in Fedora	16:25
Oxf13	jlaska: yeah, when we have to invent and manage it ourselves you're right	16:25
Oxf13	it's really a shame that RHT has such resources and aren't willing to share	16:25
adamw	jlaska: i didn't think of sorting the matrix, perhaps we could flag that up, and maybe include links to a sorted view in lili's emails?	16:25
jlaska	#info adam suggests creating links to a sorted list of "What's remaining for testing" in lili's emails	16:26
jlaska	Oxf13: there are off-the-shelf tools we could employ ... but again, I'm not real sold on the win. Frustrating for sure, but I think that's not where our valid add is	16:27
jlaska	okay, so there are some ideas here to build on for the next release	16:27
Oxf13	jlaska: what are we going to do when we have autoQA actually running tests? Are we going to have to write some sort of wiki blaster to drop test results into the wiki?	16:27
jlaska	I'll be annoying folks constantly for more of them ... so if ideas come, feel free to send to the list	16:27
jlaska	Oxf13: actually running? they're running now	16:28
jlaska	Oxf13: different topic, we can talk about that shortly	16:28
jlaska	#info Possible improvement - integration between lili and Southern_Gentlem's test matrices	16:28
jlaska	#info Possible improvement - including a link to "Remaining testing" when sending emails	16:28
jlaska	anything else I missed?	16:29
wwoods	the automated results go Elsewhere, for the moment. The simplest thing would be to keep the automated and manual tests separate and have a "automated test results are here" link.	16:29
wwoods	having autoqa edit the wiki is technically possible and probably not that hard	16:29
Southern_Gentlem	jlaska, on testing i see it as we want alot of duplication to test on as much hardware as possible	16:29
jlaska	"Is _anaconda_ broken?"	16:29
Southern_Gentlem	better to have several people sign off on one test than one	16:30
jlaska	Southern_Gentlem: good point ... we benefit from breadth of hardware coverage here ... that's something to consider	16:30
jlaska	#info Southern_Gentlem suggests having multiple testers provides better hardware diversity in testing	16:31
jlaska	okay ... let's shift gears	16:31
Southern_Gentlem	the only thing broken i have found was the nfs installs	16:31
jlaska	Southern_Gentlem: yeah, I think kparal feels your pain there too :)	16:31
kparal	right	16:31
Southern_Gentlem	which i dont consider a blocker for beta	16:31
Oxf13	wait, nfs installs broken?	16:32
Oxf13	that'd be a neat trick since I seemed to have done a few around here during the freeze	16:32
* Oxf13 is confused		16:32
kparal	https://bugzilla.redhat.com/show_bug.cgi?id=528537	16:32
jlaska	Oxf13: no they're not broken ... but there are some issues around nfs installations	16:32
buggbot	Bug 528537: medium, low, ---, steved, ASSIGNED, fails to get kickstart file over nfs.	16:32
Oxf13	ah, yeah, cobbler provides the nfs files over http	16:32
jlaska	ks=nfs: and nfsiso= both had some trouble	16:32
jlaska	lili_: anything else you wanted to share about the test matrix before we move on?	16:33
lili_	i am thinking whether our test cases need to optimize	16:34
lili_	you can move on, we can find some time to talk about this later	16:35
jlaska	lili_: okay ... I think you might be on to something ... but I don't have any great ideas at the moment :(	16:36
jlaska	if anyone has suggestions for optimizing the test runs ... please do contact lili_	16:36
jlaska	#topic AutoQA Updates from wwoods and kparal	16:36
jlaska	wwoods and kparal, I've got you both on for some updates today	16:37
jlaska	who wants to go first?	16:37
kparal	let wwoods, he has some errand :)	16:37
wwoods	heh	16:37
kparal	if i remember it correctly	16:37
wwoods	indeed	16:37
jlaska	take us away calgo^W wwoods	16:38
wwoods	let's see - we're still working on getting the production autoqa instance active	16:38
wwoods	more news on that as it happens, naturally	16:38
wwoods	I've given up on patching autotest to add info about the job ID to the tests as they run	16:39
wwoods	far simpler just to write a small "how to find test results" document	16:39
wwoods	rather than maintaining an invasive and complicated patch	16:39
wwoods	so really all that's left to do for the israwhidebroken pilot is getting everything up in production	16:40
jlaska	#info Instead of patching autotest to include a link back to test results, plans to document "How to find test logs" in the works	16:40
jlaska	wwoods: okay, I just got an update on the hardware shipment ticket today with some confusion ... I'll see if I can get more info on that	16:40
wwoods	fair enough	16:41
wwoods	so the next thing in the works is setting up a hook/watcher for koji	16:41
jlaska	#info waiting on production hardware delivery	16:41
kparal	i have seen you already started to work on that	16:41
wwoods	yes - https://fedorahosted.org/autoqa/browser/hooks/post-koji-build/watch-koji-builds.py	16:41
wwoods	it works basically like the other watchers, listing all new builds since the previous run	16:42
kparal	will you be able to also get link to the old package?	16:42
kparal	not just the new one?	16:42
wwoods	yes, I have some example code to do that	16:42
kparal	great	16:42
wwoods	but that's not really the watcher's problem	16:42
wwoods	(arguably)	16:42
wwoods	anyway, yes, it's easy to get a list of previous released versions of a new package	16:42
wwoods	we just need to figure out what data post-koji-build tests can expect/require	16:43
wwoods	and then we'll have a new hook ready to run tests	16:43
kparal	that's perfect, we can then try to hook up my script	16:43
wwoods	"url of new package(s)" seems obvious, not sure what else. possibly "tags for new package"	16:43
wwoods	if anyone has some test ideas and has a clear picture of what data the test would need to run	16:43
wwoods	please let me know	16:44
jlaska	#info Preliminary hook/watcher for koji package builds available - https://fedorahosted.org/autoqa/browser/hooks/post-koji-build/watch-koji-builds.py	16:44
wwoods	note that all the current watcher does is print a list of builds	16:44
wwoods	it doesn't run autoqa yet	16:44
wwoods	need to define test requirements before we can complete the hook	16:44
* jlaska updates more info's		16:44
wwoods	anyway I may just use package URL + tag	16:44
wwoods	for the first implementation	16:44
wwoods	and we'll move on from there.	16:45
wwoods	that's about all I've got	16:45
jlaska	#info Additional work needed on koji package watcher/hook - only prints list of builds, needs integration into autoqa	16:45
jlaska	wwoods: cool, nice work	16:45
Oxf13	right as you design this think about the future with a message bus	16:46
wwoods	ah, yes	16:46
wwoods	the koji guys are working on a plugin system for the koji hub	16:46
Oxf13	all you're going to get on the bus is "build of $foo was completed for target $bar"	16:46
wwoods	such that you can react to incoming events	16:46
jlaska	about your question ... this might be related to a different watcher ... but might lmacken be a good person to ask about what data the test would need to run?	16:46
Oxf13	the test would probably have to figure out what the previous thing was to compare against	16:46
wwoods	and, say, send out a message on a bus saying "package $nvr tagged into $tag"	16:46
mbonnet	Oxf13: not necessarily. We're probably going to provide a dict of the build info: id, name, version, release, task ID, etc.	16:47
wwoods	Oxf13: yep - that's exactly why I'm saying that code should go into the tests themselves rather than the watcher	16:47
wwoods	it's the same code either way	16:47
Oxf13	mbonnet: well sure, I meant that we wouldn't provide info like "previous build"	16:47
kparal	wwoods: only it can be duplicated in the tests	16:47
wwoods	given package name (or nvr) and tag, it's easy to look up the most recent nvr of that package for other related tags	16:47
wwoods	kparal: they can share a library	16:47
mbonnet	Oxf13: right, since koji doesn't really have a good idea of what that means	16:47
wwoods	as the rats_* tests do with rats.py	16:47
kparal	wwoods: that's true, ok	16:48
Oxf13	and there will probably be 2 types of things autoqa would want to pick up on	16:48
Oxf13	A) a build completing, and B) a build being tagged	16:48
wwoods	Oxf13: actually, no	16:48
Oxf13	since in the grand future, a build won't be tagged until /after/ the autoqa passes	16:48
wwoods	it's simpler to just wait for the build to be tagged with -candidate or -raw or something	16:48
Oxf13	erm	16:48
wwoods	and then run tests and move it to a different tag	16:48
Oxf13	we don't want to tag builds that are no good	16:48
wwoods	we can tag them with other things	16:49
Oxf13	hence wanting testing inserted before the tag action	16:49
wwoods	they can land in dist-funk-whatever-preqa	16:49
wwoods	and then run the tests	16:49
Oxf13	ugh	16:49
Oxf13	is there reasoning for this?	16:49
wwoods	mikem tells me that a) watching for untagged builds is problematic and b) tag operations are cheap	16:49
Oxf13	ok.	16:49
* kparal will be back in 30s		16:49
jlaska	kparal: okay, you're up next	16:50
jlaska	#info jkeating reminded to keep an eye towards future integration with the message bus	16:50
wwoods	the idea is the same either way, we're just quibbling over what the original trigger will be	16:50
wwoods	currently it's hard to trigger on untagged builds, later it might be easier	16:50
Oxf13	sure	16:50
wwoods	doesn't really matter in the end, we can just pick whichever way we like	16:50
Oxf13	tagging them with something just generates more mail, complicates garbage collection, and complicates our build scripts	16:50
jlaska	This seems like stuff we can iron out later, no?	16:51
Oxf13	yes	16:51
jlaska	or do we need to setup a side-discussion?	16:51
* kparal is back		16:51
jlaska	kparal: howabout on your end ... any autoqa updates?	16:52
kparal	ok, my turn. i have cheated a little and have prepared the text in the meantime. so don't wonder, i don't really type that fast :)	16:52
kparal	so, important change #1 - name: the script for displaying important differences between rpms, originally called 'packagediff', was renamed to 'rpmguard'. i believe it's a much better name, and i hope we finished renaming it :)	16:52
kparal	important change #2 - location: the autoqa project has provided hosting for the rpmguard, so you can find it in it's git, more exactly here:	16:52
kparal	http://git.fedorahosted.org/git/autoqa.git?a=tree;f=tests/rpmguard	16:52
jlaska	rpmguard at least makes for a better future icon! :)	16:52
jlaska	#info #1 - name: the script for displaying important differences between rpms, originally called 'packagediff', was renamed to 'rpmguard'	16:53
kparal	yes, rpmguard: http://cats-whisker.com/web/node/85	16:53
kparal	In the last week I have made some improvements - for example it now handles also obsoletes/conflicts changes. Also a few bugs were fixed, most notably it now correctly compares versioned require/provide/etc tags.	16:53
jlaska	#info #2 - location: the autoqa project has provided hosting for the rpmguard (see http://git.fedorahosted.org/git/autoqa.git?a=tree;f=tests/rpmguard)	16:53
kparal	I have created a few simple rpms using rpmfluff and tested if the script works ok. So hopefully it should do what it is supposed to do.	16:53
kparal	I will be very glad if you download it, try it, provide a feedback on it. But please be sure also to use latest rpmdiff from svn (prerequisite for rpmguard), because there were some important bugs fixed recently. I will also write a blogpost and post a message to mailing lists in the next days.	16:54
kparal	Also if you have some suggestions how to restructure the output of rpmguard, to be better parseable/machine processable, let me know. Especially if wwoods have some requirements what to ouput so that autoqa can utilize it, I'm all ears.	16:54
kparal	And that's probably all the news from rpmguard's world.	16:54
jlaska	kparal: I'm excited to see you able to make use of rpmfluff	16:55
jlaska	sounds like a cool tool	16:55
kparal	i have even created a first ticket for that tool:) https://fedorahosted.org/rpmfluff/report/1	16:55
jlaska	#help if interested, help test rpmguard (using latest rpmdiff from svn)	16:55
jlaska	nice work :)	16:56
jlaska	wwoods or kparal, any other items not captured, or follow-up items for next week?	16:56
kparal	nothing on my mind currently	16:57
jlaska	feel free to make liberal use of #info and #action	16:57
jlaska	okay gang, thanks for the progress updates	16:57
jlaska	Next up ... hopefully we've kept Viking-Ice around for a bit here	16:57
jlaska	#topic How_to_Debug_<component> Update from Viking-Ice	16:57
jlaska	Viking-Ice: got a few minutes to share progress / questions on your wiki initiative?	16:57
Viking-Ice	adamw: was looking into if it was doable to do this as a template	16:58
adamw	unfortunately i never got time to look at it last week. fortunately, i delegated...	16:59
adamw	<rjune> https://fedoraproject.org/wiki/How_to_debug_Dracut_problems2	16:59
adamw	https://fedoraproject.org/wiki/Template:How_to_debug2	16:59
adamw	It's a start, I'm assuming there's just too much in each variable	16:59
adamw	so rjune had a look, that's what he's come up with so far. i haven't checked it out myself yet.	16:59
Viking-Ice	I never got <notinclude><include> wiki shit to work + I think each of these pages need to be tailored to component..	16:59
jlaska	#info rjune assisted adamw in testing the use of a wiki template	16:59
jlaska	#link https://fedoraproject.org/wiki/How_to_debug_Dracut_problems2	16:59
jlaska	#link https://fedoraproject.org/wiki/Template:How_to_debug2	16:59
jlaska	That looks darned good to me	17:00
adamw	for the record, i think in theory we should be able to come up with a template which defines the general layout in a flexible enough way that we can still customize individual pages, but that's me being all mouth and no action =)	17:00
jlaska	that's what we've done with Description A brief description of the functionality being tested. How to test Start here ... Next do this ... Finally click that Expected Results Step #1 completes without error The system boots into runlevel 5 Program completes with exit code 0 ... I Don't see why we can't here	17:00
jlaska	that format leaves plenty of room for embrace + extend	17:00
adamw	so if me/rjune can't manage that in a reasonable time frame i'm not going to stand in the way of people revising pages 'statically' for sure. and we can always work on both, the static revises can always be turned into template use later.	17:00
Viking-Ice	fine if we can	17:00
Viking-Ice	I'm by no means wiki expert..	17:01
adamw	so please don't let this stop you (anyone) working on revising pages to fit the new naming scheme / layout.	17:01
jlaska	adamw: how will you know when you and rjune are done?	17:01
adamw	jlaska: when we have something we're happy with we'll send it to the list, I think	17:01
adamw	and if we get a template that's generally agreed upon we'll document its use in the Debugging category page	17:02
jlaska	sounds like a plan	17:02
Viking-Ice	so we should just rewrite those pages again? ( using the template )	17:02
Viking-Ice	instead of the current method of copy/paste the template	17:02
adamw	Viking-Ice: not right now, that template isn't finalized i don't think	17:02
Viking-Ice	ok	17:02
adamw	Viking-Ice: for now as I said we can still go ahead and revise pages using copy/paste, and then we can always adjust them to use the template later if everyone's happy with it	17:02
adamw	sound good?	17:03
Viking-Ice	yup ok	17:03
jlaska	Viking-Ice: any other items you'd like to record / discuss today?	17:03
Viking-Ice	nope nothing to share or discuss	17:04
adamw	does anyone want to take an action item to go ahead and do the renaming?	17:04
adamw	(if it's not been done already)	17:04
adamw	i think everyone agreed on the new naming scheme and there's nothing blocking us from just going ahead and renaming all pages to use it	17:04
jlaska	adamw: I can take that, that's just a ticket in to the wiki team no?	17:04
adamw	no need, you can do it directly	17:04
jlaska	sure, doesn't seem like a lot of pages	17:04
adamw	there's a 'move' button for every wiki page that lets you rename it	17:04
jlaska	yuppers	17:05
jlaska	anyone else want it?	17:05
adamw	but before you do that, make a list of all pages that link to the old name (there's a handy 'what links here' link on the left side that can tell you that) and update them all to point to the new name	17:05
adamw	there's an automatic redirect, of course, but it's best to update the links anyway - the automatic redirects break if you change name too many times, i believe	17:05
jlaska	#action jlaska to rename other debug pages (see https://fedoraproject.org/wiki/Category:Debugging) to be consistent with "How to debug <component> problems". Update back-links also	17:06
jlaska	adamw: Viking-Ice you want me to include pages we didn't produce in the move?	17:07
jlaska	e.g. Anaconda/BugReporting and "Reporting virt bugs" ?	17:07
jlaska	alrighty ... lt's move to open discussion	17:08
adamw	it may be nice to ask the people who created the pages first	17:08
jlaska	adamw: roger	17:08
adamw	but i'd envisage them being included in the end, if no-one complains	17:08
jlaska	#info existing Debugging pages using older name scheme will need to be moved	17:08
jlaska	#topic Open Discussion - <your topic here>	17:09
jlaska	okay folks ... any topics to raise that weren't discussed already?	17:09
Oxf13	We're going to need extra eyes/fingers/whatever as we get crit-path tag requests for final	17:09
adamw	is there a list to subscribe to to be notified of 'em? a list for new trac reports for releng?	17:10
Oxf13	there is the rel-eng@lists.fedorahosted.org list	17:10
Oxf13	also , rss feeds	17:10
adamw	ah, rss sounds like win	17:10
jlaska	#info Oxf13 asked for extra eyes/fingers as crit-path tag requests come in for final	17:10
jlaska	Oxf13: is there a standard set of criteria that must be provided for a crit-path package update request?	17:10
jlaska	e.g. link to bugzilla, link to patches, and an severity/impact statement?	17:11
Oxf13	there is no standard	17:11
jlaska	and must exist on F12Blocker ?	17:11
Oxf13	we didn't set one for crit-path other than "somebody else will test it"	17:11
Viking-Ice	jlaska: if we move pages should we rewrite them at the same time for the new layout ?	17:11
Oxf13	jlaska: it's really up to the reviewer what info they'll require at this point. We're still feeling our way around crit-path stuff	17:11
jlaska	Viking-Ice: I believe the edit and the move are different operations	17:11
adamw	Viking-Ice: yeah, you can do the rename without the rewrite.	17:12
adamw	and vice versa.	17:12
adamw	obviously doing both is the end goal, though. =)	17:12
Oxf13	adamw: https://fedorahosted.org/rel-eng/timeline?ticket=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss You could probably tweak that URL to get tickets only	17:12
jlaska	Oxf13: since we don't yet have the tooling or resources in place to fully qualify crit-path changes ... perhaps asking requestors to provide information to facilitate peer review?	17:12
adamw	Oxf13: thanks, i'll play with it.	17:12
Viking-Ice	Well yes but I was more thinking that we should rewrite them just delete the old one..	17:13
Viking-Ice	after rewrite ofcourse	17:13
Oxf13	jlaska: we already ask them to provide info such as what they are fixing, why, what testing they've done, and what happens if we don't include it	17:13
jlaska	Oxf13: oh okay, is there a template you ask requestors to follow?	17:13
adamw	#link https://fedorahosted.org/rel-eng/timeline?ticket=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss - rss feed to monitor tag requests	17:13
* jlaska not up on all the details of this process		17:13
Oxf13	jlaska: if they use 'make tag-request' yes	17:13
* jlaska thanks adamw for the meetbot tag		17:14
adamw	Oxf13: btw, i hadn't heard of that until it was randomly mentioned in a list post...where's it documented?	17:14
Oxf13	hadn't heard what?	17:14
Oxf13	'make tag-request' ?	17:14
adamw	yeah	17:14
Oxf13	ah, so it just got created not too long ago, and was only available to rawhide users	17:15
Oxf13	so I announced it in email hopeing to get some testing on it and do some tweaking	17:15
Oxf13	I'm mostly happy with it though, so I wouldn't mind it finding its way into a wiki page	17:15
Oxf13	but I've been... distracted	17:15
mcepl	Oxf13: https://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy	17:15
Oxf13	mcepl: feel free to add it there	17:16
mcepl	it is there	17:16
mcepl	I put it there	17:16
Oxf13	ah it's at the bottom.	17:16
jlaska	Oxf13: do you have any update on the download.fedora.devel.redhat.com and download.fedoraproject.org rawhide syncing?	17:16
Oxf13	that page could use some wiki/wordsmithing	17:16
Oxf13	jlaska: no... is it still bad?	17:16
jlaska	Oxf13: I think ... it looks like our rats_install tests are still failing do to content out of sync	17:16
Oxf13	grump	17:16
jlaska	#info rats_install tests operate against internal redhat.com mirror of rawhide ... and are failing due to what looks like out of sync content	17:17
jlaska	#link https://fedorahosted.org/pipermail/autoqa-results/2009-October/001652.html	17:17
jlaska	okay folks ... anything else to discuss today	17:17
jlaska	or should we let lili_ sleep? :)	17:17
adamw	mcepl: excellent, thanks	17:18
adamw	jlaska: just one thing	17:18
jlaska	adamw: sure, go for it	17:18
adamw	jlaska and I have been working on the common bugs page	17:18
adamw	#link https://fedoraproject.org/wiki/Common_F12_bugs	17:18
adamw	we've more or less cleared the list of bugs already tagged to be included on it	17:18
lili_	:)	17:18
adamw	if you're aware of any bug that's in the released beta images that you think should be documented there, please either add it (there's guidelines on layout in the wiki page source) or add the 'CommonBugs' keyword to the bug report, which should trigger me or jlaska or anyone else monitoring that keyword to add it	17:19
jlaska	adamw: you give me credit for common_bugs? I've had a minor contribution	17:19
adamw	oh hush with the modesty :)	17:19
jlaska	#action jlaska - help clean out remaining promised Common_F12_Bugs	17:19
adamw	basically if it's a bug more than a handful of people are likely to run into, and the workaround isn't incredibly obvious, it'd be good to have the issue listed on that page	17:20
jlaska	#link http://tinyurl.com/l4kma5 - Bugs needing Common_F12_Bugs documentation	17:20
jlaska	#info if you're aware of any bug that's in the released beta images that you think should be documented there, please either add it (there's guidelines on layout in the wiki page source) or add the 'CommonBugs' keyword to the bug report	17:20
jlaska	adamw: great reminder, thanks adamw	17:20
adamw	i'll remove Alpha issues that are fixed in the beta today, and probably add some of the generic graphics stuff from the f11 page into the f12 one as it may sadly still be needed in some cases	17:21
adamw	and just one other thing - if you're talking to anyone about how awesome f12 is going to be, reference https://fedoraproject.org/wiki/F12_Beta_Announcement for talking points. :)	17:21
jlaska	#info talking points for Fedora 12 Beta awesome-ness - https://fedoraproject.org/wiki/F12_Beta_Announcement	17:22
jlaska	right on	17:22
jlaska	alright gang ... I think that does it for today	17:22
Southern_Gentlem	i have found f12 beta to be fairly solid as far as the install process is going	17:22
adamw	yeah, i think f12 beta is actually pretty awesome. i've signed off on final distribution releases that were worse. =)	17:23
jlaska	thanks everyone for your time and to lili_ for _not_ sleeping	17:23
adamw	night lili!	17:23
Southern_Gentlem	except for the nfs issues it looks good	17:23
jlaska	let's keep our vigilence going for the coming weeks ... still have an RC yet to land	17:23
jlaska	#stopmeeting	17:23
jlaska	#endmeeting	17:23
Southern_Gentlem	jlaska, when you have isos to test ping me and if i have a little more advanced notice i will pull my test-team into testing	17:24
lili_	have a nice day,bye	17:25
jlaska	Southern_Gentlem: thank you! Right now, lili uses rel-eng hosted tickets to track updates	17:25
jlaska	nirik: did meetbot eat the minutes?	17:33
nirik	jlaska: hum. ;( not sure what happened.	17:46
nirik	jlaska: appears so. ;( Sorry about that... ;(	17:50
nirik	jlaska: might be able to replay it in at some point.	17:50
jlaska	nirik: oh, a replay would be helpful	17:53
zodbot	Oxf13: Error: Can't start another meeting, one is in progress.	18:05
Oxf13	um.	18:05
Oxf13	#endmeeting	18:05
Oxf13	jlaska: can you do #endmeeting ?	18:05
Oxf13	nirik: the bot may be stuck	18:05
nirik	oh, hang on.	18:06
nirik	.addchair nirik	18:06
zodbot	nirik: (addchair <channel> <network> <nick>) -- Add a nick as a chair to the meeting.	18:06
nirik	.addchair #fedora-meeting nirik	18:06
zodbot	nirik: (addchair <channel> <network> <nick>) -- Add a nick as a chair to the meeting.	18:06
jlaska	#endmeeting	18:07
jlaska	should I start meeting again?	18:07
jlaska	#stopmeeting	18:07
zodbot	jlaska: Error: Can't start another meeting, one is in progress.	18:07
nirik	no, hang on.	18:07
Oxf13	who's the chair?	18:07
jlaska	#endmeeting	18:07
jlaska	should be me	18:07
nirik	hum.	18:08
nirik	frack. Xchat. ;(	18:08
jlaska	#chair nirik	18:09
zodbot	Current chairs: jlaska nirik	18:09
notting	Oxf13: anything for today?	18:09
nirik	#endmeeting	18:09

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!

[1] Test_Results:Fedora_12_Beta_RC2_Install

[2] QA:Fedora_12_Install_Test_Plan

[3] ttp://spins.fedoraunity.org/Members/Southern_Gentleman/Fedora%2012%20%20beta%20TestMatrix

[1]

[2]

[3]

Search

QA/Meetings/20091019: Difference between revisions