From Fedora Project Wiki

< QA‎ | Meetings


People present (lines said):

  • jlaska (114)
  • adamw (77)
  • wwoods (69)
  • skvidal (34)
  • zodbot (5)
  • nirik (4)
  • Viking-Ice (3)
  • Oxf13 (2)



Previous meeting follow-up

  • jlaska + adamw - clear out CommonBugs? requests
    • RHBZ #541645 - PackageKit - System Update fails with PackageKit GUI ("Error getting ...
      • Removed from CommonBugs?
    • RHBZ #552423 - gnome-panel - [abrt] crash in gnome-panel (/usr/libexec/wnck-applet @ w...
      • jlaska to check with halfline for details

Fedora 13 QA Retrospective

Owner - User:Jlaska
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
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
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
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
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
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
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
Mether asked adamw to raise this topic for quick discussion to determine if there is any corrective action for QA.
Next steps...
  1. Adamw sending wwoods a simple summary of the test scenario
  2. Wwoods will determine if the existing depcheck test would have detected this failure case

AutoQA handling of branched and rawhide

Owner - User:wwoods
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...
  1. At branch point in release, someone will need to add entries to repoinfo.conf when the branched repos appear
  2. jlaska took an action item to document the changes and add a link to the existing SOP for branching the release

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

  1. jlaska will discuss CommonBugs entry for 552423 with halfline
  2. Adamw will propose a document 'What do proventesters test for'?
  3. jlaska to check-in with lmacken on the status of
  4. Someone needs to check with bodhi on when 'proventester' karma is required for critpath packages
  5. jlaska to update QA/Join to include link to proventester page
  6. adamw to forward wwoods a good explanation of the nss-softokn problem scenario to ensure autoqa catches it in future
  7. 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 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 - 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 has the juice 15:09
jlaska Worst case, it's easy for someone to add it back along with guidance -- 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 15:18
jlaska #action jlaska to check-in with lmacken on the status of 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 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@ -- 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 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 2.7 by Marius Gedminas - find it at!