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.
- jlaska - reach out to beland for guidance/ideas on how to document the process for how bugs bubble through different release documents
- beland sent email to fedora-test-list (see http://lists.fedoraproject.org/pipermail/test/2010-January/088137.html)
- jlaska took action to add bz links to the Common_F13_bugs page
- 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
- Milestone - https://fedorahosted.org/autoqa/milestone/autoqa%20depcheck
- Owner - User:wwoods
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
- Milestone - https://fedorahosted.org/autoqa/milestone/Package%20update%20tests
- Owner - User:kparal
Last week
- Test results are now sent to autoqa-results, the next large step is ...
- Continue discussing and start requirements gathering for a more formal method for collecting and presenting package update test results (see https://fedorahosted.org/pipermail/autoqa-devel/2010-January/000120.html)
- Most of last week in RHCT training
- Discovered that some packages can be improperly detected by rpmguard (see https://fedorahosted.org/pipermail/autoqa-devel/2010-January/000143.html)
This week
- Address ticket#114
- Kparal interested in developing design goals for results db
install automation
- Milestone - https://fedorahosted.org/autoqa/milestone/Automate%20installation%20test%20plan
- Owner - User:lili, User:rhe
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
- Milestone - https://fedorahosted.org/autoqa/milestone/Packaging%20and%20Review
- Owner - User:jlaska
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
- Process akurtakov's feedback and remove all uncertain JAR files from the list (see User:Jlaska/gwt#Status_uncertain).
Current status on packaging:
- gwt-* - Still scoping out packaging needs (see User:Jlaska/gwt)
- autoqa - packaged (see autoqa-0.3-2.fc12.src.rpm), will submit once autotest-client is accepted
- autotest-client - undergoing review - RHBZ #548522
- autotest - packaged (see autotest-0.11.0-4.el5.src.rpm, will submit for review after gwt* accepted
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:
- Automated rats_install fail
- Timeouts due to slow link in PHX2 (infrastructure investigating)
- Problems with compose format - rats_install doesn't yet support splitting out stage2= and repo=
- Manual tests pass when using http://jlaska.fedorapeople.org/updates-557588.img
- Results available at Test_Results:Fedora_13_Rawhide_Acceptance_Test_1.
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
- jlaska to add bugzilla shared query links to Common_Bugs wiki page
- jlaska and beland to keep working on the process
- 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 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!