From Fedora Project Wiki
Attendees
People present (lines said):
- jlaska (114)
- adamw (77)
- wwoods (69)
- skvidal (34)
- zodbot (5)
- nirik (4)
- Viking-Ice (3)
- Oxf13 (2)
Regrets:
Agenda
Previous meeting follow-up
- jlaska + adamw - clear out CommonBugs? requests
Fedora 13 QA Retrospective
- Owner - User:Jlaska
- Summary
- Feedback on QA execution of Fedora 13 testing is available at Fedora_13_QA_Retrospective. This document is intended to serve as a roadmap for Fedora 14 QA planning.
- Next steps...
- Jlaska planning to organize Fedora_13_QA_Retrospective feedback and present initial draft of recommendations next week.
Proventester status
- Owner - User:Maxamillion
- Summary
- Adam Miller announced that the proventesters wiki page (QA/JoinProvenTesters) is no longer a draft. We have several TRAC requests to join the proventesters group. User:Adamwill asked whether we can start processing proventesters requests. What's next, and who is needed to take it there?
- Next steps
- adamw will propose a document 'What do proventesters test for'?
- jlaska to check-in with lmacken on the status of https://fedorahosted.org/bodhi/ticket/424
- jlaska to update QA/Join to include link to proventester page
- Someone needs to check with bodhi team on plans for requiring 'proventester' karma feedback for critpath packages for F-13-updates.
AutoQA initscripts test validation
- Owner - User:Jskladan
- Summary
- Josef asked for help in validating a new round of SysVinitscript AutoQA tests. See announcement and instructions and blog.
- Next steps...
- Unclear, will check-in with Josef.
AutoQA prioritization
- Owner - User:Jlaska
- Summary
- The immediate goal is to automate the QA:Package_Update_Acceptance_Test_Plan. Kparal asked, what is the most efficient way to prioritize and balance outstanding tasks to accomplish this goal? The current open milestones tracking progress toward this goal include:
- Next steps...
-
- Jlaska and wwoods felt that depcheck was the highest priority of the listed tasks
- Need to discuss with kparal and jskladan for further input
Open discussion - <Your topic here>
What's in autoqa-0.3.5-1?
- Owner - User:wwoods
- Summary
- With several patches now in master, Wwoods asked if there were any other changes planned for the next version of autoqa (
autoqa-0.3.5-1)? - Next steps...
-
- wwoods would like to get post-bodhi-update watch into autoqa-0.3.5-1
- Enable an existing test to run for post-bodhi-update watcher (rpmlint or rpmguard)
Future of rpmlint
- Owner - User:skvidal, User:kparal
- Summary
- Seth and Kamil have been discussing how to improve rpm static and comparative tests in the future. The general idea is to provide a test framework such that it is easy to document how to add new tests. General discussion available at autoqa-devel.
- Next steps...
- Time permitting, Seth will propose a draft framework for review to autoqa-devel
NSS Dependency Issue
- Owner - User:Adamwill
- Summary
- Mether asked adamw to raise this topic for quick discussion to determine if there is any corrective action for QA.
- Next steps...
-
- Adamw sending wwoods a simple summary of the test scenario
- Wwoods will determine if the existing depcheck test would have detected this failure case
AutoQA handling of branched and rawhide
- Owner - User:wwoods
- Summary
- Wwoods discussed recent autoqa changes and how it impacts testing of rawhide and branched.
- post-koji-build only triggers for branched (there are no nightly rawhide install images)
- Next steps...
-
- At branch point in release, someone will need to add entries to
repoinfo.confwhen the branched repos appear - jlaska took an action item to document the changes and add a link to the existing SOP for branching the release
- At branch point in release, someone will need to add entries to
Upcoming QA events
- 2010-07-08 - Pre-Alpha Rawhide Acceptance Test Plan #1
- 2010-07-15 - Pre-Alpha Rawhide Acceptance Test Plan #2
- 2010-07-22 - Pre-Alpha Rawhide Acceptance Test Plan #3
- 2010-07-23 - Alpha Blocker Meeting (f14alpha) #1
- 2010-07-30 - Alpha Blocker Meeting (f14alpha) #2
Action items
- jlaska will discuss CommonBugs entry for 552423 with halfline
- Adamw will propose a document 'What do proventesters test for'?
- jlaska to check-in with lmacken on the status of https://fedorahosted.org/bodhi/ticket/424
- Someone needs to check with bodhi on when 'proventester' karma is required for critpath packages
- jlaska to update QA/Join to include link to proventester page
- adamw to forward wwoods a good explanation of the nss-softokn problem scenario to ensure autoqa catches it in future
- jlaska to add autoqa FIXME links for a wiki page describing how to update repoinfo.conf when branched release is available, linked from the existing branched SOP pages
IRC Transcript
| jlaska | #startmeeting Fedora QA Meeting | 15:00 |
|---|---|---|
| zodbot | Meeting started Mon Jun 7 15:00:16 2010 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| zodbot | Useful Commands: #action #agreed #halp #info #idea #link #topic. | 15:00 |
| jlaska | #meetingname fedora-qa | 15:00 |
| zodbot | The meeting name has been set to 'fedora-qa' | 15:00 |
| jlaska | #topic Gathering critical mass | 15:00 |
| jlaska | okay, it's show of hands time | 15:00 |
| * adamw shows off a hand he found on the weekend | 15:01 | |
| jlaska | I believe we are without kparal and jskladan may be late | 15:01 |
| adamw | it's fun because it's decomposing! | 15:01 |
| jlaska | adamw: eeew | 15:01 |
| jlaska | hopefully, rhe and lili are sleeping | 15:02 |
| jlaska | I don't believe wwoods is in yet, so this may be the shortest meeting : | 15:03 |
| jlaska | adamw: Well, let's cover what we can | 15:03 |
| jlaska | Proposed agenda - http://lists.fedoraproject.org/pipermail/test/2010-June/091438.html | 15:04 |
| jlaska | #topic Previous meeting follow-up | 15:04 |
| jlaska | it's been a while since our last IRC meeting, and the only item on my list was ... | 15:04 |
| jlaska | #info jlaska + adam - clear out CommonBugs? requests | 15:04 |
| adamw | is wwoods out in the park with a brown bag socializing with hobos again? | 15:04 |
| * Viking-Ice half inn half out.. | 15:04 | |
| adamw | hiya viking | 15:04 |
| adamw | we pretty much did the commonbugs, i think | 15:05 |
| jlaska | adamw: he might be, possibly executing Kentucky dumpster test with them | 15:05 |
| adamw | =) | 15:05 |
| jlaska | Viking-Ice: hey there! | 15:05 |
| jlaska | adamw: right, there are only 2 bugs left | 15:05 |
| Viking-Ice | Greetings guys.. | 15:05 |
| adamw | i think i left them alone because i didn't understand them =) | 15:05 |
| jlaska | hah, me too! :) | 15:05 |
| * jlaska checks if there are updates or a high DUP count | 15:05 | |
| jlaska | no updates on bug#541645, I'd like to propose removing the CommonBugs keyword for that one | 15:06 |
| jlaska | the other bug (bug#552423), does have some recent activity | 15:06 |
| jlaska | and a ton of DUPs | 15:06 |
| jlaska | I have no idea, I can ping halfline if he has anything thoughts what to document here | 15:07 |
| jlaska | #action jlaska will discuss CommonBugs entry for 552423 with halfline | 15:07 |
| jlaska | adamw: any objection to dropping 541645 from the list? | 15:07 |
| adamw | not really. it's an f12 bug and doesn't really seem that common | 15:08 |
| jlaska | okay | 15:08 |
| adamw | oh wait hold on | 15:08 |
| adamw | i think i remember what this is now | 15:08 |
| * jlaska looks for the "Unsubmit" button | 15:08 | |
| adamw | i think this is the infamous 'first update on a fresh f12 install fails' bug isn't it? | 15:08 |
| adamw | oh no, it's something different | 15:09 |
| jlaska | okay | 15:09 |
| adamw | https://bugzilla.redhat.com/show_bug.cgi?id=541645#c33 has the juice | 15:09 |
| jlaska | Worst case, it's easy for someone to add it back along with guidance -- http://fedoraproject.org/wiki/Common_F13_bugs#My_bug_is_not_listed | 15:09 |
| jlaska | okay, jumping into the agenda ... and again, without kparal, jskladan or wwoods ... this will be fast | 15:10 |
| adamw | yeah, it seems pretty messy, let's knock it off for now. | 15:10 |
| adamw | yeah, because we sure don't do anything =) | 15:10 |
| jlaska | adamw: we're just for show :) | 15:10 |
| * adamw is wearing his bikini | 15:10 | |
| * jlaska thinks about margaret thatcher on a cold day | 15:11 | |
| jlaska | #topic Fedora 13 QA Retrospective | 15:11 |
| jlaska | Alright, no surprise here, but this is top on my priority list now | 15:11 |
| jlaska | #info Feedback on QA execution of Fedora 13 testing is available at Fedora_13_QA_Retrospective. This document is intended to serve as a roadmap for Fedora 14 QA planning. | 15:11 |
| adamw | what specifically are the next steps here? | 15:11 |
| jlaska | #info Next steps ... Jlaska planning to organize Fedora_13_QA_Retrospective feedback and present initial draft of recommendations next week. | 15:11 |
| jlaska | I intend to follow the same process I used for F12 (Fedora_12_QA_Retrospective#Recommendations), but might adjust if something else works better | 15:12 |
| adamw | cool | 15:12 |
| jlaska | basically, I'll just be organizing the content provided by everyone into groups/themes | 15:12 |
| jlaska | and we can optionally pick off action items from this | 15:13 |
| jlaska | I'd like to try something a little different this time | 15:13 |
| jlaska | much like we did for F13 test days, I'd like to have links to fedora-qa TRAC tickets for any action taken | 15:13 |
| jlaska | or any proposals | 15:13 |
| jlaska | I'd like to make it easier to determine how well we did what we said we would do | 15:14 |
| adamw | sounds good | 15:14 |
| jlaska | so that's all on this topic | 15:14 |
| jlaska | questions/comments/concerns? | 15:14 |
| * jlaska notes ... he's using a new format for meeting topics (owner, summary, next steps) | 15:14 | |
| jlaska | okay, next topic ... | 15:15 |
| jlaska | #topic Proventester status | 15:15 |
| jlaska | maxamillion (has a conflict right now) and adamw discussed some next steps on the list last week | 15:15 |
| jlaska | #info Adam Miller announced that the proventesters wiki page (QA/JoinProvenTesters) is no longer a draft. | 15:15 |
| adamw | so, we put the policy in place, we just need to start accepting mentor requests | 15:15 |
| jlaska | #info We have several TRAC requests to join the proventesters group. | 15:15 |
| adamw | it would probably help to throw together a page which lists what proventesters actually *test* for, according to the list discussion | 15:16 |
| adamw | i can do that if desired | 15:16 |
| jlaska | adamw: yes! | 15:16 |
| jlaska | I think we talked about that in a previous meeting, but it was mid-RC release so of course, there was no time | 15:16 |
| adamw | then the OTHER obvious next step is to co-ordinate with releng in getting the gating instated: we should make sure they know that things are all go on our side | 15:16 |
| jlaska | when you say gating? | 15:17 |
| adamw | can you throw that in as a #action for me? | 15:17 |
| adamw | what the proventesters schtick is all actually for - having updates require proventester feedback | 15:17 |
| jlaska | #action Adamw will propose a document 'What do proventesters test for'? | 15:17 |
| adamw | right now, proventester input isn't needed | 15:17 |
| jlaska | ah yes, 'qa' input is needed, but we need to get infrastructure to change that group to 'proventesters' | 15:18 |
| jlaska | we've got a ticken open for that ... I'll ping lmacken there | 15:18 |
| jlaska | #link https://fedorahosted.org/bodhi/ticket/424 | 15:18 |
| jlaska | #action jlaska to check-in with lmacken on the status of https://fedorahosted.org/bodhi/ticket/424 | 15:18 |
| adamw | no, right now, there aren't any restrictions on updates, aiui | 15:18 |
| jlaska | oh interesting, even for critpath? | 15:19 |
| adamw | f13 had them in pre-release phase but doesn't now it's been released, and other stable releases never had 'em | 15:19 |
| adamw | yup. | 15:19 |
| * jlaska thought we turned them back on | 15:19 | |
| adamw | hum, you may be more up to date than me | 15:19 |
| jlaska | okay, so yeah, that's not ideal | 15:19 |
| adamw | anyway we should check =) | 15:19 |
| adamw | Oxf13: not around to clarify are you? | 15:19 |
| jlaska | #action check with release engineering on whether 'proventester' karma is required for critpath packages | 15:19 |
| jlaska | okay, so we've got 3 next steps so far 1) draft SOP-like 'proventester' instructions, 2) enable bodhi use of 'proventester' group, 3) turn on 'proventester' karma requirement for critpath | 15:21 |
| jlaska | anything else we need to consider? | 15:21 |
| adamw | that seems like enough for nwo | 15:21 |
| adamw | also now | 15:21 |
| jlaska | adamw: before we start working the outstanding proventester fedora-qa requests, I'd like to get our instructions nailed down first. What do you think? | 15:21 |
| adamw | sure, we can do that quick. | 15:22 |
| jlaska | do we need to link in the new proven tester page from the wiki QA namespace? | 15:22 |
| jlaska | may already be there, /me looks | 15:22 |
| adamw | ah, good point | 15:23 |
| jlaska | Special:WhatLinksHere/QA/JoinProvenTesters | 15:23 |
| jlaska | Doesn't appear so, so probably an #action to add it to QA/Join | 15:23 |
| jlaska | I'll be happy to take that | 15:23 |
| jlaska | I think I'll just reword the existing section "Testing official updates before they are released" | 15:24 |
| jlaska | any objections? | 15:24 |
| jlaska | I'll send to the list for feedback/concerns | 15:24 |
| adamw | that was the way i was thinking too | 15:24 |
| jlaska | #action jlaska to update QA/Join to include link to proventester page | 15:24 |
| jlaska | okay, the remaining topics I have were AutoQA | 15:25 |
| jlaska | I'll reserve those for when jskladan, kparal and wwoods are around | 15:25 |
| * wwoods appears | 15:25 | |
| Oxf13 | adamw: I'm not really around, just getting ready for another meeting. | 15:25 |
| jlaska | wwoods: hey! | 15:26 |
| * jlaska needs to step away in 4 minutes | 15:26 | |
| wwoods | so yeah, autoqa update. what did we do last week? oh right | 15:26 |
| Oxf13 | adamw: I know that the intent is that we will be turning on provenpackager restriction for critpath packages for F13 updates, I don't know if the code has been written yet to make that happen. | 15:26 |
| jlaska | wwoods: one sec ... lemme update topic | 15:26 |
| jlaska | #topic AutoQA initscripts test validation | 15:26 |
| jlaska | #info Josef asked for help in validating a new round of SysVinitscript AutoQA tests. | 15:26 |
| jlaska | #link http://lists.fedoraproject.org/pipermail/test/2010-May/091311.html | 15:26 |
| jlaska | I'll stub leave this topic here for Josef to add any thoughts in the mailing list minutes | 15:27 |
| jlaska | so far we've had a few contributors, thanks maxamillion and sferguson! | 15:27 |
| jlaska | #topic AutoQA prioritization | 15:27 |
| jlaska | wwoods: kparal raised this topic during one of our discussions | 15:28 |
| jlaska | #info The immediate goal is to automate the QA:Package_Update_Acceptance_Test_Plan. What is the most efficient way to prioritize and balance outstanding tasks to accomplish this goal? | 15:28 |
| wwoods | wow, good question | 15:28 |
| jlaska | We can discuss this more with everyone involved available, but with the several different roadmaps we have going on ... Kparal asked whether it would help if we prioritize on one or two, and all pitch in to accomplish that milestone | 15:28 |
| wwoods | seems like the automation infrastructure work (e.g. the post-bodhi-update hook) is a key first step but yeah, beyond that.. | 15:29 |
| jlaska | wwoods: yeah, I agree ... that seems to touch on several new topics that are required by the subsequent efforts | 15:29 |
| jlaska | so, let's leave this open for Kamil and Josef to join in also | 15:29 |
| wwoods | definitely | 15:29 |
| wwoods | it's an Important Discussion. | 15:30 |
| jlaska | but the thinking is if we all agree on the priority, we would all change gears and work on the same milestone | 15:30 |
| jlaska | okay ... I'll jump to open discussion next ... | 15:30 |
| jlaska | wwoods, I have your autoqa question there, and any other topics are welcome of course | 15:31 |
| jlaska | #topic Open discussion - What's in autoqa-0.3.5-1? | 15:31 |
| jlaska | #info With several patches now in master, Wwoods asked if there were any other changes planned for the next version of autoqa (autoqa-0.3.5-1)? | 15:31 |
| wwoods | so yeah - we got jobtag passing / link construction into the latest (0.3.4?) build | 15:31 |
| wwoods | and.. what else? | 15:31 |
| jlaska | there was nothing else I was tracking | 15:32 |
| wwoods | well, we have some fixes for handling branched and rawhide | 15:32 |
| jlaska | yeah, with the 0.3.5 changes, we get the updated repoinfo stuff to enable rawhide build verification | 15:32 |
| wwoods | so probably we should try to land the post-bodhi-update hook | 15:33 |
| wwoods | and any other fixes needed to make that run as expected | 15:33 |
| wwoods | but beyond that there's no obvious "we need this feature soon!" things in my head - if anyone has any suggestions please say so | 15:33 |
| adamw | ponies! | 15:34 |
| Viking-Ice | unicorns pony's are so lame.. | 15:34 |
| wwoods | that's slated for zero-dot-four-dot-NEVER | 15:34 |
| jlaska | wwoods: sounds like your post-bodhi-update work just about ready then, is that something you're targeting for this week? | 15:34 |
| wwoods | jlaska: yeah - as a quick update, I've got the watcher running, and the actual hook code | 15:35 |
| wwoods | plus the templates and a little documentation | 15:35 |
| jlaska | sweet! | 15:35 |
| wwoods | the remaining piece is to move rpmguard to that hook | 15:35 |
| wwoods | or perhaps copy - it might still run as a post-koji-build test for new rawhide builds | 15:36 |
| jlaska | okay | 15:36 |
| adamw | oh, what do we think of the discussion on devel list about rpmlint output, btw? should we be bugging rpmlint upstream, or our rpmlint packager, to customize the rules? | 15:36 |
| wwoods | we should drop rpmlint | 15:36 |
| wwoods | imho. | 15:36 |
| jlaska | adamw: skvidal has some good thoughts on how best to work with upstream on rpmlint | 15:36 |
| wwoods | but maybe that's just me. | 15:36 |
| skvidal | hi | 15:37 |
| adamw | hi! | 15:37 |
| skvidal | wwoods: I think you're not entirely wrong :) | 15:37 |
| skvidal | I think there are some rpmlint tests which are handy | 15:37 |
| skvidal | but there are an arseload of them which are just silly | 15:37 |
| wwoods | right, and I think those tests should be integrated into rpmguard | 15:37 |
| jlaska | the discussion definitely raises the idea that improvements are needed | 15:37 |
| skvidal | rpmguard's structure needs some love to make it easier for folks to write tests | 15:37 |
| jlaska | #topic Open discussion - future of rpmlint | 15:37 |
| skvidal | I said I would work on that and I'm planning on doing so - we'll see what I'm able to get out of it | 15:38 |
| adamw | rpmguard was supposed to have a clearly distinguished function from rpmlint | 15:38 |
| wwoods | and I get the feeling that ratio of important:barely-useful-or-trivial rpmlint tests is a pretty small number | 15:38 |
| jlaska | #info adamw asked how we should handle the devel@ thread around rpmlint | 15:38 |
| adamw | it's not supposed to be Fedora's Awsum Rpmlint Replacement | 15:38 |
| skvidal | adamw: okay | 15:38 |
| skvidal | here's the problem | 15:38 |
| skvidal | rpmlint checks things about A PACKAGE | 15:38 |
| skvidal | rpmguard checks things between pkgs | 15:38 |
| wwoods | right, they're totally separate tests. one tests a single package, totally free of context | 15:38 |
| skvidal | what we want, I think, is to let more people write tests | 15:39 |
| skvidal | period | 15:39 |
| adamw | i mean, i'm happy if we decide for our purposes rpmguard testing is all we want, and we don't want to bother with rpmlint. but i just want to make sure we keep the distinction between what the two are for. | 15:39 |
| skvidal | and we will find that often people will want to do BOTH - test A package and test the pkgs NOT in a vacuum | 15:39 |
| jlaska | #info More discussion on autoqa-devel@ -- https://fedorahosted.org/pipermail/autoqa-devel/2010-June/000616.html | 15:39 |
| wwoods | and the other is checking specifically for difference between two packages, within the context of the Fedora repos | 15:39 |
| skvidal | wwoods: in the context of the repos is the next layer up, I think | 15:39 |
| skvidal | so if you think of what we're testing as objects | 15:39 |
| skvidal | repos -> sets of pkgs -> a pkg | 15:39 |
| skvidal | rpmlint is 'a pkg' | 15:40 |
| skvidal | rpmguard is 'sets of pkgs' (though right now now that best choice of sets, I think) | 15:40 |
| skvidal | and repos is the repoclosure/diff tests | 15:40 |
| skvidal | so if we have packagechecking tool that just hands the test the set of pkgs related to the new build | 15:40 |
| wwoods | what I mean is: since rpmguard is testing against the previously-released version of a package - which implicitly means "whatever the last released Fedora package was" - the test actually has some vague concept of the existence of Fedora repos | 15:40 |
| skvidal | then the test-author can choose what the hell they want to test | 15:41 |
| wwoods | it's not testing the repo per se. | 15:41 |
| skvidal | wwoods: it has knowledge of older pkgs of the same base srpm origin | 15:41 |
| wwoods | but yeah, I agree rpmguard should be a framework - or that we need a framework | 15:41 |
| skvidal | so in that framework | 15:41 |
| skvidal | if we wanted to have one of the tests be | 15:41 |
| jlaska | #chair adamw | 15:41 |
| zodbot | Current chairs: adamw jlaska | 15:41 |
| * jlaska double booked at the moment | 15:42 | |
| skvidal | run rpmlint and this specific set of tests | 15:42 |
| skvidal | that would make sense to me | 15:42 |
| adamw | okay. obviously we'd want kparal's input on all of this too | 15:42 |
| wwoods | right | 15:42 |
| wwoods | see here's the problem - now you're defining a test framework within a test framework | 15:42 |
| skvidal | adamw: sure - that's why I was posting to autoqa-devel last week | 15:42 |
| wwoods | or rather, an autoqa test which is actually a harness for other sub-tests | 15:43 |
| skvidal | wwoods: agreed - but the goal of that is to make the tests easier for authors to write | 15:43 |
| wwoods | right, we want people to contribute test snippets to this thing | 15:43 |
| skvidal | b/c the testing framework for autoqa currently is WAY TOO MUCH to get into for a simple 'does this rpm differ from this other one' | 15:43 |
| skvidal | or 'does this pkg have broken unicode in some random-ass path' | 15:44 |
| skvidal | or 'does this pkg have more than 50K provides' or whatever | 15:44 |
| wwoods | just need to be careful to design this thing in a way that doesn't make us start reimplementing chunks of autoqa inside a test | 15:44 |
| skvidal | for simple tests you shouldn't have to learn the testing infrastructure very much | 15:44 |
| skvidal | wwoods: which is why I posted a very very simple structure for it to the list | 15:45 |
| wwoods | I need to review that but that was one of my concerns | 15:45 |
| wwoods | I'll think more on it and reply on-list basically | 15:45 |
| skvidal | ok | 15:45 |
| wwoods | but in short, you've hit the nail on the head: we want to define a convention for these tests | 15:45 |
| wwoods | how they get their inputs and what they should give as output | 15:46 |
| wwoods | so the rpmguard (or whatever) harness can just run through 'em all | 15:46 |
| wwoods | and that harness should be a standard autoqa test, so it can send its outputs to the standard resultsdb | 15:47 |
| adamw | okay, sounds like you agree on a direction to move in | 15:47 |
| wwoods | and we can use our standard (future-planned) tools for handling waiving failures &c | 15:47 |
| adamw | do we have other topics for open discussion? | 15:47 |
| jlaska | gang, I'm involved in another meeting at the moment. I've asked adamw to help bring the meeting to a close | 15:48 |
| wwoods | understood, no problem | 15:48 |
| * adamw has one if no-one else does =) | 15:48 | |
| wwoods | I'm tapped out, me | 15:49 |
| adamw | okay | 15:49 |
| adamw | #topic Open discussion - nss dependency issue | 15:49 |
| adamw | so, this was actually suggested by mether | 15:49 |
| adamw | he suggested we have a quick chat about the issue with i686 nss in the x86-64 repo that's caused some pain in the last week or two | 15:50 |
| adamw | is everyone broadly aware of the actual issue here? | 15:50 |
| * jlaska not well versed in this issue, but interested in learning from it | 15:50 | |
| adamw | well, a quick recap, as I understand it: | 15:51 |
| adamw | we have the i686 packages built from 'nss' .src.rpm in the x86-64 repo | 15:51 |
| adamw | but nss itself is not directly marked as a multilib package: they just get pulled in as dependencies of packages that *are* marked as multilib | 15:51 |
| adamw | now what happened is that an update was issued for nss | 15:52 |
| adamw | since no package in the _updates_ repo for f13 currently has a dependency on nss, the i686 packages from the update did _not_ go into the x86-64 update repo | 15:52 |
| * nirik notes this is nss-softokn specifically. | 15:52 | |
| adamw | right, sorry | 15:52 |
| wwoods | this sounds like a mash bug? | 15:53 |
| nirik | https://admin.fedoraproject.org/updates/nss-softokn-3.12.4-23.fc13 | 15:53 |
| adamw | so if you were running x86-64 fedora with some i686 package which required nss-softokn , when you did updates, you got breakage, because there's a newer x86-64 package but not the matching new i686 package | 15:53 |
| nirik | add karma there and confirm it fixes it. | 15:53 |
| adamw | there's various ways to look at it, really | 15:53 |
| adamw | it's one of those things where we could strengthen any one bit of the chain and avoid the bug | 15:54 |
| adamw | i believe that update addresses it by improving how the dependencies are stated in the package. you could also fix it in mash, i guess, or you could mark it as explicitly multilib | 15:54 |
| wwoods | right. so why is this a QA issue? | 15:55 |
| adamw | i think our topic for discussion is whether we can think of any way the whole thing could have been handled better / faster, and whether there was anything qa could have done that we didn't | 15:55 |
| adamw | wwoods: that was my thought when mether suggested it, but it is worth a quick chat, i guess, in case anyone thinks we dropped any balls here | 15:55 |
| wwoods | we aren't responsible for the tools that create the repos, or making decisions about the multilib flag, or the package deps | 15:55 |
| wwoods | there are certainly tests we could run that would *detect* this situation and prevent it from getting into the repos | 15:56 |
| nirik | I think we might have caught this in updates-testing if critical path had still been enabled. | 15:56 |
| adamw | no, but this is a bug in the release, we're responsible in some degree for catching the bug and making sure it gets addressed by the devel/eng folks | 15:56 |
| wwoods | and it's worth making sure that depcheck would catch this | 15:56 |
| adamw | wwoods: right, that's another good point, we should make sure the autoqa tests we plan to implement will catch such a scenario in future\ | 15:56 |
| wwoods | the problem is definitely not our responsibility. but part of our charter is to provide tools that prevent (or, failing that, detect) these things when they do happen | 15:57 |
| wwoods | so I'm honestly not sure what depcheck would do in that situation | 15:58 |
| wwoods | in theory it should do whatever yum did - i.e. barf | 15:58 |
| adamw | well, we don't need to answer it right now, just make sure it's on your radar as something to check | 15:58 |
| wwoods | so I haven't explicitly tested this, but depcheck should, in theory, notice it and refuse to allow that package to be pushed live | 15:59 |
| wwoods | but can you do me a favor and send me a very simple summary of the scenario - something I can turn into a test case | 15:59 |
| wwoods | in an email? | 15:59 |
| wwoods | or just gimme a link to someone else's explanation of the problem | 16:00 |
| adamw | okay, i'll try and find the best explanation to forward | 16:00 |
| wwoods | depcheck should prevent this in the future; I'll write a test case to ensure that it properly handles that scenario | 16:00 |
| adamw | #action adamw to forward wwoods a good explanation of the nss-softokn problem scenario to ensure autoqa catches it in future | 16:01 |
| adamw | well, i guess that's all the juice in that one | 16:01 |
| adamw | anything else for open floor, or shall we go eat cookies? | 16:01 |
| * jlaska notes, no topics from me | 16:02 | |
| wwoods | I've got one little thing | 16:03 |
| wwoods | for the record, a quick summary of how autoqa will handle branched/rawhide | 16:03 |
| wwoods | basically: the post-tree-compose hook only triggers for branched, since rawhide doesn't involve boot images | 16:04 |
| adamw | #topic Open floor - AutoQA handling branched and rawhide | 16:04 |
| wwoods | and also - obviously - bodhi isn't involved in the rawhide workflow | 16:05 |
| wwoods | so any testing that we want to do involving rawhide should target either the post-koji-build hook | 16:05 |
| wwoods | or the post-repo-update hook | 16:05 |
| wwoods | as appropriate to the thing you're trying to test. | 16:05 |
| wwoods | once we hit branched, post-tree-compose (and soon post-bodhi-update) will also be viable test hooks | 16:06 |
| wwoods | once the release happens, post-tree-compose goes fallow again | 16:06 |
| wwoods | I think at this point we've updated the watchers / repoinfo data to handle these things as expected | 16:07 |
| adamw | great | 16:07 |
| wwoods | we need to add entries to the repoinfo config when the branched repos appear but other than that everything should just kind of roll along automatically | 16:07 |
| wwoods | so that's that. | 16:07 |
| adamw | thanks | 16:07 |
| jlaska | #action add FIXME links for a wiki page describing the changes, linked from the existing branched SOP pages | 16:08 |
| jlaska | #undo | 16:08 |
| zodbot | Removing item from minutes: <MeetBot.items.Action object at 0x2b7acfd038d0> | 16:08 |
| jlaska | #action add autoqa FIXME links for a wiki page describing how to update repoinfo.conf when branched release is available, linked from the existing branched SOP pages | 16:08 |
| wwoods | yeah it's pretty straightforward: when we branch, the rawhide tag changes, and some new repos get created. | 16:09 |
| wwoods | so we need to edit repoinfo.conf and... change the rawhide tag, and create some new repo entries | 16:09 |
| wwoods | makes sense, right? | 16:09 |
| jlaska | definitely, thanks! | 16:09 |
| adamw | okay, so i think that's all | 16:11 |
| adamw | thanks for coming everyone! | 16:13 |
| adamw | #endmeeting | 16:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!