From Fedora Project Wiki

< QA‎ | Meetings

Revision as of 13:41, 26 January 2010 by Jlaska (talk | contribs) (Corrected notes)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Attendees

People present (lines said)

  • adamw (120)
  • jlaska (46)
  • wwoods (41)
  • kparal (18)
  • maxamillion (17)
  • beland (11)
  • Oxf13 (9)
  • nirik (4)

Regrets:

Agenda

Previous meeting follow-up

  • maxamillion bring back conversation about Xfce 4.8 updato on xfce@lists.fp.o and inform about conclusion
    • Features/Xfce48
    • there's not much to report ... its mainly a waiting game on our end but I also know we need to start planning out a Test day
    • Will continue monitoring XFCE 4.8 schedule, and may choose to hold a test day even if it slips.
  • adamw to build on the famous spot security blog post and draft something quick'n'dirty for QA review
    • Adam drafted a policy and sent for review (see http://lists.fedoraproject.org/pipermail/test/2010-January/088063.html)
    • Signifant feedback so far, the policy has gone through several iterations.
    • Adam will review updates over the weekend, and submit another update for review
    • Once enough people are satisfied with policy ... will submit to FESCO for review
  • nirik intends to update the Releases/Rawhide wiki page to reflect the changes (help appreciated)
    • nirik is waiting for the subpackage (fedora-release-rawhide) to land

AutoQA project update

Deps/conflicts prevention

Last week

  • lmacken working an API change into the next release of bodhi
  • A close to working depsolv test case (see [1]) is available. Further clean-up needed.

This week

  • bodhi code required for the post-bodhi-update hook is now in bodhi (thanks lmacken)
  • wwoods working with skvidal and other rpm hackers to try and solve the depcheck problem
  • wwoods looking for help in doing the post-bodhi-update hook
  • kparal has code for generating fake RPMs for testing in git as rpmguard_test.py

rpmguard and autoqa results collection

Last week

This week

  • Address ticket#114
  • Kparal interested in developing design goals for results db

install automation

Last week

  • Continue working towards a single python test that will automate a DVD install

This week

  • Publish test code using either a public git branch, code on a people page, just a local git checkout
  • Continue test development

packaging/deployment

Last week

  • Continue to harden the next-steps for JARs in the uncertain (see User:Jlaska/gwt#Status_uncertain). AdamW reached out to akurtakov for thoughts on uncertain JARs.
  • Merged autotest and autotest-client packages using the single upstream source. Started moving content into standard Fedora locations. The new packages will come from a single .spec file and build autotest (client) and autotest-server (server). This seems to make more packaging sense and helps focus efforts on GWT for the time being.

This week

Current status on packaging:

Open discussion - <Your topic here>

Rawhide Acceptance Testing

Last week, 2010-01-21 was the first pre-Alpha rawhide acceptance test milestone. Jkeating worked around a glibc bug by including the previous build. Install images were built and posted on alt.fedoraproject.org. Since AutoQA doesn't yet monitor this location for new install images, tests were initiated manually.

Test Summary:

Next Steps:

  • Fix AutoQA rats_install to support stage2= and repo= values
  • Fix AutoQA post-tree-compose hook to monitor for RAT droppings (see ticket#115)
  • 2010-01-28 test run (see rel-eng ticket#3292)

Upcoming QA events

  • 2010-01-21 - Pre-Alpha Rawhide Acceptance Test Plan #1
  • 2010-01-28 - Pre-Alpha Rawhide Acceptance Test Plan #2
  • 2010-02-04 - Pre-Alpha Rawhide Acceptance Test Plan #3
  • 2010-02-05 - Alpha Blocker Meeting (F13Alpha) #1
  • 2010-02-11 - Test Alpha 'Test Compose' (boot media testing)
  • 2010-02-12 - Alpha Blocker Meeting (F13Alpha) #2

Action items

  1. jlaska to add bugzilla shared query links to Common_Bugs wiki page
  2. jlaska and beland to keep working on the process
  3. wwoods and kparal to talk about design ideas

IRC transcript

adamw #startmeeting qa meeting 2010-01-25 16:03
zodbot Meeting started Mon Jan 25 16:03:07 2010 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:03
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:03
adamw good $TIMEZONE_APPROPRIATE_GREETING everybody 16:03
adamw #topic gathering 16:03
adamw who's around? 16:03
jlaska I'll be around for the start of the meeting now 16:03
* kparal is 16:03
* maxamillion is semi-here ... in a $dayjob meeting with my laptop 16:04
adamw hey beland 16:05
adamw alright then, let's get started with last week's review 16:05
adamw #topic followup: xfce test day / 4.8 update 16:05
adamw maxamillion: got anything for us on this? 16:06
maxamillion adamw: well, yes and no ... I think I talked to you about this in the #fedora-qa channel but not in a meeting because I missed last week 16:06
adamw well in a meeting context! 16:06
maxamillion we're following the Xfce 4.8 development cycle pretty closely and there's apparently the concept of a 2 month release slip happening so we're monitoring that to decide what we should do for a QA Test Day 16:07
maxamillion errr... concept of the 2 month release slip is being thrown around, but not definite yet 16:07
maxamillion sorry ... trying to listen to $dayjob meeting while typing, I apparently didn't do that well 16:08
adamw so the 2 month slip would be from when to when? 16:08
maxamillion but other than that, there's not much to report ... its mainly a waiting game on our end but I also know we need to start planning out a Test day 16:08
maxamillion adamw: just a sec, lemme get a link 16:08
maxamillion adamw: http://fedoraproject.org/wiki/Features/Xfce48 <--- if they have the 2 month slip, we will miss Fedora 13 16:09
maxamillion it is currectly an agressive time line just to make F13 with them being on time 16:09
adamw if you're looking for advice i'd say not to risk it, then, it's a very bad idea to depend on an upstream project being precisely on time =) but anyway 16:10
* wwoods appears 16:10
adamw i guess the main issue for QA group is the test day, so planning on that has not advanced much? 16:10
maxamillion adamw: well the plan for me is to pick a date for the xfce test day, and pick a "if we don't have a pre release on time, then we revert to 4.6 testing" date 16:11
jlaska so we'll be testing something, whether it's 4.8 or 4.6 will be decided later? 16:12
maxamillion jlaska: right, but my fear is that if we don't get to move forward to 4.8, then we won't really have much new to add to the last test day 16:12
maxamillion because in the world of xfce .. not a whole lot has changed 16:13
adamw that's fine; you can just have a 'is everything still working okay' test day 16:13
adamw nothing wrong with that 16:13
maxamillion adamw: sounds good to me 16:13
adamw even if nothing changed in xfce itself, lots of underlying code has changed, you'll want to be sure xfce bits still work okay with it 16:13
maxamillion oh yeah, definitely ... I was just hoping to have shiny new xfce features to test :D 16:14
adamw =) 16:14
adamw ok, thanks maxa 16:14
adamw anything else on xfce anyone? 16:14
maxamillion nothing from me 16:14
adamw alrighty 16:14
adamw #topic followup - bug documentation 16:14
adamw jlaska / beland, this is yours 16:15
adamw agenda notes 'beland sent email to fedora-test-list (Re: 2010-01-11 @ 16:00 UTC (11am EST) - Fedora QA Meeting Recap) ' 16:15
adamw i think i missed that one... 16:15
jlaska yeah, I had an email in progress, but beland beat me to it :) 16:15
adamw oh, just yesterday evening, haven't read it yet 16:15
jlaska so discussion started in response to last week's meeting recap (see http://lists.fedoraproject.org/pipermail/test/2010-January/088137.html) 16:15
jlaska I seemed to have a hard time deciding how to address documentation issues during previous releases 16:16
jlaska I think that's cleared up for me now, but I'm not sure if it would be beneficial to others to spell it out as well 16:16
beland Just read James' reply...I guess it would be useful to hear opinions on whether the CommonBugs keyword is useful. 16:17
jlaska I don't hear any complaints, so I gather not 16:17
adamw well james and I use it ourselves a lot, i dunno if it really gets used beyond that 16:17
adamw I also use it to know when changes to a bug should get echoed back to the common bugs page... 16:17
beland Any particular reason you don't just add links to the wiki page instead? 16:17
jlaska I use it quite a bit for tagging issues that come up during test ... just to make sure that adamw or I get a chance to later review the issue appropriateness (word?) for the common_bug wiki 16:18
adamw beland: for what purpose? 16:19
jlaska beland: the only reason I don't add it directly to the wiki, is that the bug might be too new (or to in flux) that the details needed to properly document aren't yet fleshed out 16:19
adamw beland: you can't put 'placeholders' on the wiki page, it's a production page for people to read; putting them in the source is too easy to miss; and a backlink from the wiki to the bug doesn't help you know the page needs updating when you're reading the *bug* 16:19
jlaska s/or to in/or too in/ 16:19
beland Sounds like it's useful enough to justify the extra complication, then. 16:20
beland We should add links to the queries jlaska pointed out in his email, then. 16:20
jlaska beland: where would you prefer seeing those links, on the Common_Bugs wiki page? 16:21
beland Yeah. 16:21
jlaska If no objections, I can add those links at the end of #My_bug_is_not_listed 16:22
adamw sounds good 16:22
adamw damn sorry been forgetting my #info's, here we go 16:22
jlaska #action jlaska to add bugzilla shared query links to Common_Bugs wiki page 16:22
adamw #info jlaska and beland working on the topic 16:22
adamw jlaska: i don't think I chaired you, hand on 16:23
adamw #action jlaska to add bugzilla shared query links to Common_Bugs wiki page 16:23
adamw #chair jlaska 16:23
zodbot Current chairs: adamw jlaska 16:23
beland I think the idea of "if you want to add a note to formal documentation about a bug, file a bug report against the documentation" is good advice, even if it's not the most efficient workflow in the world. 16:23
beland I'm not sure where that should be documented for QA-type people to find, though. It would be nice if it were clearly documented for everyone in the Docs Project wikispace, but ::sigh:: 16:23
adamw personally i honestly don't think i'd consistently wade through a bunch of 'bug reports against documentation' to find stuff to add to common_bugs 16:24
adamw if anyone else would, great 16:24
beland No, I wouldn't include Common Bugs there. 16:24
adamw oh, kay. 16:24
beland Just "formal documentation" that's off-wiki. 16:24
beland (stuff on docs.fedoraproject.org) 16:25
adamw #info beland thinks filing bug reports to request notes be added to formal documentation is the best procedure 16:25
adamw alright, so basically the update for this topic is that it's in progress and discussed on-list 16:25
adamw is there anything else we need to discuss in the meeting context? 16:25
jlaska I don't think so, that's all I have on the topic 16:26
jlaska thanks beland :) 16:26
adamw #action jlaska and beland to keep working on the process 16:26
adamw #topic privilege escalation policy 16:27
adamw okay, this one is me. so, as you probably saw on-list, I sent out a draft policy 16:27
adamw and everyone has got involved in explaining why it sucks :) 16:27
adamw i'll keep re-drafting until everyone agrees with more or has been bored into submission 16:27
adamw s/more/me/ 16:27
adamw once we have a good draft i'll take it back up to fesco 16:28
beland Whee! 16:28
adamw is that process ok with everyone? 16:28
maxamillion kudos for taking on this task ... its definitely a big one 16:28
jlaska I'm not fully up to speed on the updates over the weekend, but it seems to be moving forward 16:28
adamw or does anyone feel they want to be more involved is this exciting and highly rewarding endeavour? :P 16:28
maxamillion i read over it and have no objections 16:28
adamw i haven't done squat over the weekend 16:28
adamw but i'll pick up the latest mails today and send out a new draft 16:29
adamw #info adamw still working on re-drafting the policy with much group feedback on mailing list 16:30
adamw #topic followup: rawhide page update 16:31
adamw this is for nirik, if you're around 16:31
nirik I'm around... 16:31
adamw nirik was planning to update the rawhide wiki page to reflect the changes to getting On The Bus 16:31
nirik I'm waiting for the subpackage to land. 16:31
adamw #link http://fedoraproject.org/wiki/Releases/Rawhide 16:31
adamw fair enough - waiting as in you have the change ready to go when it does, or waiting as in you'll write it when it does? :) 16:32
nirik I'll write it when it does. ;) 16:32
nirik If someone else wants to, feel free. ;) 16:32
adamw alrighty! 16:33
adamw #info nirik waiting on actual commit of the rawhide package change before updating the wiki 16:33
* jlaska joins another meeting ... lurking here 16:33
adamw okay, the only other thing on the agenda is a giant autoqa topic 16:34
adamw #topic autoqa: packaging/deployment 16:34
adamw jlaska: can you give us a quick packaging update before you go? 16:34
jlaska adamw: sure ... 16:34
jlaska the latest updates are on the wiki ... 16:35
jlaska I spent last week playing around with repackaging the current autotest-client package. Long story short, I think it makes sense now to combine autotest and autotest-client 16:35
adamw jlaska: did you get the pointers from akurtakov? 16:35
jlaska into a single package 16:35
jlaska so with that in mind, that helps shift the focus over to the BuildRequires tasks ... 16:36
jlaska which is what adamw mentioned 16:36
jlaska Adam reached out to akurtakov for help identifying what's up with the remaining unknown bundled JAR files in the gwt package 16:36
jlaska #link https://fedoraproject.org/wiki/User:Jlaska/gwt 16:36
jlaska I'll be processing that feedback this week and hopefully removing the uncertain table altogether 16:37
jlaska once that's done ... it's package time 16:37
adamw akurtakov being someone who actually knows stuff about java :) 16:37
jlaska so that's where things are on the packaging front 16:38
adamw alrighty, thanks jlaska 16:38
adamw #info jlaska planning to combine autotest-client and autotest into one package this week, and continue to clean up the gwt packaging plan so we can get started on it 16:38
adamw #topic autoqa: dependency checking 16:38
adamw wwoods: take it away! where are we on depcheck? 16:39
wwoods it's, uh 16:40
adamw ... 16:40
wwoods it's a thing 16:40
adamw ooh there he is. 16:40
wwoods wheels are turning, but it's a complex problem with a lot of different possible approaches 16:41
wwoods and so I've got one mostly-functional prototype that I'm realizing has some shortcomings and I may need to try a different approach 16:41
wwoods to avoid writing (and thus having to maintain) a totally duplicate copy of the depsolving algorithm in my own code 16:42
adamw that would suck. 16:42
wwoods anyway the code I needed for the post-bodhi-update hook is apparently in bodhi now (thanks lmacken!) 16:42
adamw i realize this is probably me being stupid, but can't you just re-use yum's code? 16:42
wwoods adamw: no. that's part of the problem. 16:43
wwoods I mean. Parts of it, yes, but not all of it, and not directly.. it's complicated 16:43
adamw okay, that's good enough for me! 16:43
wwoods the yum API is designed to accomplish a certain set of tasks easily and efficiently - mostly, y'know, processing updates and removing packages and such 16:43
* adamw has terrifying visions of half-hour explanations he doesn't understand 16:44
wwoods so this task doesn't really line up easily with any of the stuff that yum currently provides. 16:44
adamw #info wwoods still not sure how to tackle the complex question of actual depcheck code: has one mostly-working prototype but making it fully-working is hard and may require a new approach 16:44
adamw is there anything anyone can help you with here? 16:44
wwoods it may turn out that I'll be adding some bits to yum, or it may turn out that I need to use the rpmlib stuff directly, or maybe I just need some yum code and some glue 16:44
adamw besides being a genius and going 'no, you fool, you should do it THIS way!'? 16:45
wwoods mostly I'm bugging skvidal (and will probably bother ffesti/panu/other rpm hackers) about how depsolving works/should work 16:45
wwoods unfortunately there's no obvious bit of this I could break off and ask someone to help with 16:45
adamw #info bodhi code required for the post-bodhi-update hook is now in bodhi 16:46
wwoods oh actually - if someone wants to look into the post-bodhi-update hook/watcher, that might be good 16:46
adamw #info wwoods working with skvidal and other rpm hackers to try and solve the depcheck problem 16:46
wwoods also if anyone has experience using rpmfluff (?) (maybe kparal?) to generate fake RPMs for test cases 16:46
adamw #info someone else could help take the load off wwoods by doing the post-bodhi-update hook 16:46
adamw any volunteers? 16:46
wwoods that would be really useful 16:46
kparal wwoods: I have created a few simple rpms, it was quite easy 16:47
wwoods kparal: is that code in the autoqa repo? 16:47
kparal wwoods: actually I think it is. rpmguard_test.py 16:47
adamw #info kparal has code for generating fake RPMs for testing in git as rpmguard_test.py 16:48
wwoods nice. I'll check that out. 16:48
kparal adamw: it's not even worth an info :) 16:48
wwoods heh! 16:48
wwoods nah, you're the first one to claim to know about it 16:48
wwoods now you're the resident expert! 16:48
wwoods congratulations! 16:48
adamw you still haven't figured out how this stuff works, have you kparal? :DD 16:49
adamw never volunteer! 16:49
wwoods heh 16:49
kparal :D 16:49
adamw okay i'm gonna cut you off there so we can get through everything else 16:49
* kparal is learning by mistakes 16:49
wwoods anyway yeah, depcheck progress is slowish but it's a big problem 16:49
adamw #topic autoqa: rpmguard and autoqa results collection 16:49
wwoods it seems that nobody else has stuck to it long enough to finish it off 16:49
* adamw applies glue to wwoods 16:50
wwoods so that's the goal: KILL IT DEAD 16:50
adamw alright, kparal - take it away, what's happening in the rpmguard world 16:50
kparal as for rpmguard, there is nothing truly new for the last week. I was attending the RHCT course (and passed :)), but didn't have time to improve rpmguard 16:50
kparal we have just found out that some packages can fly under our radar and not to be compared, but I don't know if that's not more than week old news 16:51
kparal here's the link: https://fedorahosted.org/pipermail/autoqa-devel/2010-January/000143.html 16:52
adamw congrats kparal! 16:53
adamw #info kparal discovered some packages can be missed by the rpmguard test 16:53
kparal the big step ahead would be the results database, what do you think, wwoods? 16:53
wwoods a results database would be really, really useful 16:54
wwoods but it's a pretty significant engineering effort 16:54
adamw right, that's under this topic too 16:54
adamw database...and associated server? 16:54
kparal not only useful but I think necessary, if we want to leverage the results somehow in the future 16:54
kparal and yes, it's certainly not an easy task 16:55
wwoods right. the tricky part is making it general enough to be useful for all our tests 16:55
wwoods but specific enough to hold all the info you need for every test result 16:55
wwoods it's a really tough problem to solve 16:55
adamw #info kparal and wwoods agree that an autoqa results database+server would be very useful 16:55
wwoods we should certainly talk more about design ideas 16:55
wwoods I definitely agree we need some way of aggregating/reviewing test data 16:56
adamw #info wwoods notes it would take significant engineering effort and also requires solving the problem of being general enough to useful for all possible autoqa tests but also handle all info for each specific test 16:56
adamw #action wwoods and kparal to talk about design ideas 16:56
adamw this feels like something you may want more people for, to me 16:56
adamw you're both pretty busy already 16:56
wwoods but there's a lot to consider - does it need to be able to link with/talk to bugzilla? trac? upstream bug trackers? get info from CVS/git? do we want this to wait for the QA Message Bus? 16:57
kparal I think we start to have useful tests in autoqa, the next problem would be to use the data collected. so I suppose we slow down now on test engineering effort and start working on this results database 16:57
wwoods I think we can talk about design goals now without getting too bogged down in implementation details 16:57
wwoods err, "now" meaning "in this timeframe" not "during this specific meeting" 16:57
kparal yes, our "now" is not really exactly now :) 16:58
wwoods there's a lot of planning work to do - but don't let that stop you from designing/setting up a prototype system 16:58
wwoods the JFDI methodology is useful here 16:58
wwoods and it helps make better plans if you've actually tried to build something similar before 16:59
* kparal googling 16:59
wwoods heh - "just fucking do it" 16:59
adamw alrighty we'll await next week's update with interest 16:59
adamw finally before open discussion: 16:59
adamw #topic autoqa: installation automation 16:59
adamw this is lili / rhe stuff - does someone have an update from them? 16:59
kparal adamw: it's on the wiki I suppose 17:00
kparal well, not exactly 17:00
kparal 2 bullets 17:00
jlaska I got a link to lili's latest script today, I'm going to reply with some feedback and encourage getting the content posted somewhere (git repo or branch) 17:01
adamw #info lili has continued to update the automated installation script, jlaska will ask him to upload the current work somewhere public 17:01
adamw okay 17:04
adamw i think that's everything on the agenda 17:04
adamw #topic open discussion 17:05
adamw bring yer topics here! anyone have anything else to discuss? 17:05
adamw ...i guess not 17:06
jlaska oh ... rawhide acceptance testing ... 17:06
* jlaska grabs a link 17:07
adamw #topic open discussion: rawhide acceptance testing 17:07
adamw oh yes that was going to happen last week 17:07
adamw #info there was supposed to be an installer image drop for rawhide testing on 2010-01-21 17:08
adamw right jlaska? 17:08
jlaska yup, so jkeating was able to pull an install source together and work around the glibc bug 17:08
jlaska with that ... I launched some rats_install tests at the new tree 17:08
Oxf13 it happened, and we foudn bugs 17:08
jlaska http://jlaska.fedorapeople.org/rats-20100121.png has the latest results 17:08
adamw #link http://jlaska.fedorapeople.org/rats-20100121.png is all the shiny results 17:09
adamw so it sort of failed a bit! excellent. 17:09
jlaska yeah fail :( 17:09
jlaska we found an immediate issue, and then Hans from the installer team fixed it 17:10
jlaska [Bug 557588] File "/usr/lib/anaconda/iw/filter_gui.py", line 634 17:10
jlaska I pulled that fix into an updates.img and was testing again, but ran into some other issues 17:10
jlaska the link to alt.fp.org is also much slower after the move, so I need to check-in with infrastructure. 17:11
Oxf13 infra has provided us with a second download site 17:11
Oxf13 that syncs from alt 17:11
adamw #info installer team is working to fix the bugs exposed by the test 17:11
jlaska Oxf13: oh, so I should be using a different url? 17:11
Oxf13 next time we do a drop we're going to measure the lag time of that second download site getting the content to gage whether or not this is a solution 17:12
Oxf13 jlaska: we'll try next time 17:12
jlaska Oxf13: okay 17:12
jlaska Oxf13: same as last time, shall I submit a ticket to rel-eng for the compose 17:12
Oxf13 infra is aware of the poor performance and has opened a ticket internally to RHT regarding this 17:12
jlaska ? 17:12
Oxf13 yep 17:12
jlaska cool 17:12
Oxf13 releng now has an SOP for how to deal with those tickets 17:12
Oxf13 thanks to poelcat 17:12
adamw excellent 17:12
adamw any other business? 17:13
jlaska adamw: so that's all I had, just wanted to let folks know what happened, and the plan for this week 17:13
adamw alrighty then 17:14
adamw it's gavel-bangin' time 17:14
adamw thanks for coming everyone 17:14
jlaska adamw: thanks for driving :) 17:14
adamw #endmeeting 17:14

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

Retrieved from "https://fedoraproject.org/w/index.php?title=QA/Meetings/20100125&oldid=147847"