15:00:16 <jlaska> #startmeeting Fedora QA Meeting
15:00:16 <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:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:20 <jlaska> #meetingname fedora-qa
15:00:20 <zodbot> The meeting name has been set to 'fedora-qa'
15:00:45 <jlaska> #topic Gathering critical mass
15:00:54 <jlaska> okay, it's show of hands time
15:01:19 * adamw shows off a hand he found on the weekend
15:01:20 <jlaska> I believe we are without kparal and jskladan may be late
15:01:24 <adamw> it's fun because it's decomposing!
15:01:26 <jlaska> adamw: eeew
15:02:15 <jlaska> hopefully, rhe and lili are sleeping
15:03:09 <jlaska> I don't believe wwoods is in yet, so this may be the shortest meeting  :
15:03:38 <jlaska> adamw: Well, let's cover what we can
15:04:03 <jlaska> Proposed agenda - http://lists.fedoraproject.org/pipermail/test/2010-June/091438.html
15:04:09 <jlaska> #topic Previous meeting follow-up
15:04:32 <jlaska> it's been a while since our last IRC meeting, and the only item on my list was ...
15:04:40 <jlaska> #info jlaska + adam - clear out CommonBugs? requests
15:04:43 <adamw> is wwoods out in the park with a brown bag socializing with hobos again?
15:04:53 * Viking-Ice half inn half out..
15:04:57 <adamw> hiya viking
15:05:13 <adamw> we pretty much did the commonbugs, i think
15:05:13 <jlaska> adamw: he might be, possibly executing Kentucky dumpster test with them
15:05:15 <adamw> =)
15:05:18 <jlaska> Viking-Ice: hey there!
15:05:24 <jlaska> adamw: right, there are only 2 bugs left
15:05:27 <Viking-Ice> Greetings guys..
15:05:37 <adamw> i think i left them alone because i didn't understand them =)
15:05:43 <jlaska> hah, me too! :)
15:05:59 * jlaska checks if there are updates or a high DUP count
15:06:30 <jlaska> no updates on bug#541645, I'd like to propose removing the CommonBugs keyword for that one
15:06:42 <jlaska> the other bug (bug#552423), does have some recent activity
15:06:53 <jlaska> and a ton of DUPs
15:07:15 <jlaska> I have no idea, I can ping halfline if he has anything thoughts what to document here
15:07:31 <jlaska> #action jlaska will discuss CommonBugs entry for 552423 with halfline
15:07:40 <jlaska> adamw: any objection to dropping 541645 from the list?
15:08:09 <adamw> not really. it's an f12 bug and doesn't really seem that common
15:08:17 <jlaska> okay
15:08:18 <adamw> oh wait hold on
15:08:32 <adamw> i think i remember what this is now
15:08:40 * jlaska looks for the "Unsubmit" button
15:08:42 <adamw> i think this is the infamous 'first update on a fresh f12 install fails' bug isn't it?
15:09:12 <adamw> oh no, it's something different
15:09:16 <jlaska> okay
15:09:23 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=541645#c33 has the juice
15:09:48 <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:10:13 <jlaska> okay, jumping into the agenda ... and again, without kparal, jskladan or wwoods ... this will be fast
15:10:18 <adamw> yeah, it seems pretty messy, let's knock it off for now.
15:10:27 <adamw> yeah, because we sure don't do anything =)
15:10:38 <jlaska> adamw: we're just for show :)
15:10:46 * adamw is wearing his bikini
15:11:05 * jlaska thinks about margaret thatcher on a cold day
15:11:16 <jlaska> #topic Fedora 13 QA Retrospective
15:11:29 <jlaska> Alright, no surprise here, but this is top on my priority list now
15:11:40 <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:44 <adamw> what specifically are the next steps here?
15:11:54 <jlaska> #info Next steps ... Jlaska planning to organize Fedora_13_QA_Retrospective feedback and present initial draft of recommendations next week.
15:12:35 <jlaska> I intend to follow the same process I used for F12 (https://fedoraproject.org/wiki/Fedora_12_QA_Retrospective#Recommendations), but might adjust if something else works better
15:12:55 <adamw> cool
15:12:57 <jlaska> basically, I'll just be organizing the content provided by everyone into groups/themes
15:13:13 <jlaska> and we can optionally pick off action items from this
15:13:19 <jlaska> I'd like to try something a little different this time
15:13:34 <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:41 <jlaska> or any proposals
15:14:13 <jlaska> I'd like to make it easier to determine how well we did what we said we would do
15:14:21 <adamw> sounds good
15:14:29 <jlaska> so that's all on this topic
15:14:32 <jlaska> questions/comments/concerns?
15:14:57 * jlaska notes ... he's using a new format for meeting topics (owner, summary, next steps)
15:15:12 <jlaska> okay, next topic ...
15:15:15 <jlaska> #topic Proventester status
15:15:41 <jlaska> maxamillion (has a conflict right now) and adamw discussed some next steps on the list last week
15:15:50 <jlaska> #info Adam Miller announced that the proventesters wiki page (QA/JoinProvenTesters) is no longer a draft.
15:15:51 <adamw> so, we put the policy in place, we just need to start accepting mentor requests
15:15:59 <jlaska> #info We have several TRAC requests to join the proventesters group.
15:16:18 <adamw> it would probably help to throw together a page which lists what proventesters actually *test* for, according to the list discussion
15:16:21 <adamw> i can do that if desired
15:16:28 <jlaska> adamw: yes!
15:16:44 <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:52 <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:17:08 <jlaska> when you say gating?
15:17:09 <adamw> can you throw that in as a #action for me?
15:17:26 <adamw> what the proventesters schtick is all actually for - having updates require proventester feedback
15:17:34 <jlaska> #action Adamw will propose a document 'What do proventesters test for'?
15:17:36 <adamw> right now, proventester input isn't needed
15:18:04 <jlaska> ah yes, 'qa' input is needed, but we need to get infrastructure to change that group to 'proventesters'
15:18:16 <jlaska> we've got a ticken open for that ... I'll ping lmacken there
15:18:35 <jlaska> #link https://fedorahosted.org/bodhi/ticket/424
15:18:53 <jlaska> #action jlaska to check-in with lmacken on the status of https://fedorahosted.org/bodhi/ticket/424
15:18:55 <adamw> no, right now, there aren't any restrictions on updates, aiui
15:19:04 <jlaska> oh interesting, even for critpath?
15:19:07 <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:14 <adamw> yup.
15:19:14 * jlaska thought we turned them back on
15:19:21 <adamw> hum, you may be more up to date than me
15:19:22 <jlaska> okay, so yeah, that's not ideal
15:19:24 <adamw> anyway we should check =)
15:19:36 <adamw> Oxf13: not around to clarify are you?
15:19:53 <jlaska> #action check with release engineering on whether 'proventester' karma is required for critpath packages
15:21:13 <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:22 <jlaska> anything else we need to consider?
15:21:46 <adamw> that seems like enough for nwo
15:21:52 <adamw> also now
15:21:55 <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:22:13 <adamw> sure, we can do that quick.
15:22:37 <jlaska> do we need to link in the new proven tester page from the wiki QA namespace?
15:22:42 <jlaska> may already be there, /me looks
15:23:05 <adamw> ah, good point
15:23:07 <jlaska> https://fedoraproject.org/wiki/Special:WhatLinksHere/QA/JoinProvenTesters
15:23:32 <jlaska> Doesn't appear so, so probably an #action to add it to https://fedoraproject.org/wiki/QA/Join
15:23:37 <jlaska> I'll be happy to take that
15:24:04 <jlaska> I think I'll just reword the existing section "Testing official updates before they are released"
15:24:11 <jlaska> any objections?
15:24:33 <jlaska> I'll send to the list for feedback/concerns
15:24:45 <adamw> that was the way i was thinking too
15:24:52 <jlaska> #action jlaska to update https://fedoraproject.org/wiki/QA/Join to include link to proventester page
15:25:15 <jlaska> okay, the remaining topics I have were AutoQA
15:25:41 <jlaska> I'll reserve those for when jskladan, kparal and wwoods are around
15:25:42 * wwoods appears
15:25:42 <Oxf13> adamw: I'm not really around, just getting ready for another meeting.
15:26:01 <jlaska> wwoods: hey!
15:26:18 * jlaska needs to step away in 4 minutes
15:26:19 <wwoods> so yeah, autoqa update. what did we do last week? oh right
15:26:24 <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:27 <jlaska> wwoods: one sec ... lemme update topic
15:26:36 <jlaska> #topic AutoQA initscripts test validation
15:26:50 <jlaska> #info Josef asked for help in validating a new round of SysVinitscript AutoQA tests.
15:26:55 <jlaska> #link http://lists.fedoraproject.org/pipermail/test/2010-May/091311.html
15:27:10 <jlaska> I'll stub leave this topic here for Josef to add any thoughts in the mailing list minutes
15:27:41 <jlaska> so far we've had a few contributors, thanks maxamillion and sferguson!
15:27:51 <jlaska> #topic AutoQA prioritization
15:28:03 <jlaska> wwoods: kparal raised this topic during one of our discussions
15:28:12 <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:32 <wwoods> wow, good question
15:28:55 <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:29:05 <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:29 <jlaska> wwoods: yeah, I agree ... that seems to touch on several new topics that are required by the subsequent efforts
15:29:51 <jlaska> so, let's leave this open for Kamil and Josef to join in also
15:29:54 <wwoods> definitely
15:30:07 <wwoods> it's an Important Discussion.
15:30:18 <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:49 <jlaska> okay ... I'll jump to open discussion next ...
15:31:02 <jlaska> wwoods, I have your autoqa question there, and any other topics are welcome of course
15:31:17 <jlaska> #topic Open discussion - What's in autoqa-0.3.5-1?
15:31:26 <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:42 <wwoods> so yeah - we got jobtag passing / link construction into the latest (0.3.4?) build
15:31:50 <wwoods> and.. what else?
15:32:25 <jlaska> there was nothing else I was tracking
15:32:45 <wwoods> well, we have some fixes for handling branched and rawhide
15:32:59 <jlaska> yeah, with the 0.3.5 changes, we get the updated repoinfo stuff to enable rawhide build verification
15:33:06 <wwoods> so probably we should try to land the post-bodhi-update hook
15:33:16 <wwoods> and any other fixes needed to make that run as expected
15:33:45 <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:34:03 <adamw> ponies!
15:34:15 <Viking-Ice> unicorns pony's are so lame..
15:34:18 <wwoods> that's slated for zero-dot-four-dot-NEVER
15:34:54 <jlaska> wwoods: sounds like your post-bodhi-update work just about ready then, is that something you're targeting for this week?
15:35:14 <wwoods> jlaska: yeah - as a quick update, I've got the watcher running, and the actual hook code
15:35:21 <wwoods> plus the templates and a little documentation
15:35:33 <jlaska> sweet!
15:35:40 <wwoods> the remaining piece is to move rpmguard to that hook
15:36:28 <wwoods> or perhaps copy - it might still run as a post-koji-build test for new rawhide builds
15:36:28 <jlaska> okay
15:36:34 <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:41 <wwoods> we should drop rpmlint
15:36:48 <wwoods> imho.
15:36:51 <jlaska> adamw: skvidal has some good thoughts on how best to work with upstream on rpmlint
15:36:57 <wwoods> but maybe that's just me.
15:37:03 <skvidal> hi
15:37:11 <adamw> hi!
15:37:15 <skvidal> wwoods: I think you're not entirely wrong :)
15:37:23 <skvidal> I think there are some rpmlint tests which are handy
15:37:30 <skvidal> but there are an arseload of them which are just silly
15:37:34 <wwoods> right, and I think those tests should be integrated into rpmguard
15:37:38 <jlaska> the discussion definitely raises the idea that improvements are needed
15:37:55 <skvidal> rpmguard's structure needs some love to make it easier for folks to write tests
15:37:55 <jlaska> #topic Open discussion - future of rpmlint
15:38:08 <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:13 <adamw> rpmguard was supposed to have a clearly distinguished function from rpmlint
15:38:18 <wwoods> and I get the feeling that ratio of important:barely-useful-or-trivial rpmlint tests is a pretty small number
15:38:20 <jlaska> #info adamw asked how we should handle the devel@ thread around rpmlint
15:38:23 <adamw> it's not supposed to be Fedora's Awsum Rpmlint Replacement
15:38:29 <skvidal> adamw: okay
15:38:32 <skvidal> here's the problem
15:38:40 <skvidal> rpmlint checks things about A PACKAGE
15:38:50 <skvidal> rpmguard checks things between pkgs
15:38:56 <wwoods> right, they're totally separate tests. one tests a single package, totally free of context
15:39:05 <skvidal> what we want, I think, is to let more people write tests
15:39:06 <skvidal> period
15:39:22 <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:24 <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:26 <jlaska> #info More discussion on autoqa-devel@ -- https://fedorahosted.org/pipermail/autoqa-devel/2010-June/000616.html
15:39:26 <wwoods> and the other is checking specifically for difference between two packages, within the context of the Fedora repos
15:39:39 <skvidal> wwoods: in the context of the repos is the next layer up, I think
15:39:47 <skvidal> so if you think of what we're testing as objects
15:39:53 <skvidal> repos -> sets of pkgs -> a pkg
15:40:04 <skvidal> rpmlint is 'a pkg'
15:40:15 <skvidal> rpmguard is 'sets of pkgs' (though right now now that best choice of sets, I think)
15:40:23 <skvidal> and repos is the repoclosure/diff tests
15:40:51 <skvidal> so if we have packagechecking tool that just hands the test the set of pkgs related to the new build
15:40:55 <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:41:00 <skvidal> then the test-author can choose what the hell they want to test
15:41:05 <wwoods> it's not testing the repo per se.
15:41:19 <skvidal> wwoods: it has knowledge of older pkgs of the same base srpm origin
15:41:22 <wwoods> but yeah, I agree rpmguard should be a framework - or that we need a framework
15:41:44 <skvidal> so in that framework
15:41:49 <skvidal> if we wanted to have one of the tests be
15:41:50 <jlaska> #chair adamw
15:41:50 <zodbot> Current chairs: adamw jlaska
15:42:03 * jlaska double booked at the moment
15:42:04 <skvidal> run rpmlint and this specific set of tests
15:42:13 <skvidal> that would make sense to me
15:42:29 <adamw> okay. obviously we'd want kparal's input on all of this too
15:42:33 <wwoods> right
15:42:50 <wwoods> see here's the problem - now you're defining a test framework within a test framework
15:42:53 <skvidal> adamw: sure - that's why I was posting to autoqa-devel last week
15:43:18 <wwoods> or rather, an autoqa test which is actually a harness for other sub-tests
15:43:25 <skvidal> wwoods: agreed - but the goal of that is to make the tests easier for authors to write
15:43:53 <wwoods> right, we want people to contribute test snippets to this thing
15:43:55 <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:44:18 <skvidal> or 'does this pkg have broken unicode in some random-ass path'
15:44:27 <skvidal> or 'does this pkg have more than 50K provides' or whatever
15:44:40 <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:43 <skvidal> for simple tests you shouldn't have to learn the testing infrastructure very much
15:45:07 <skvidal> wwoods: which is why I posted a very very simple structure for it to the list
15:45:24 <wwoods> I need to review that but that was one of my concerns
15:45:33 <wwoods> I'll think more on it and reply on-list basically
15:45:49 <skvidal> ok
15:45:56 <wwoods> but in short, you've hit the nail on the head: we want to define a convention for these tests
15:46:02 <wwoods> how they get their inputs and what they should give as output
15:46:14 <wwoods> so the rpmguard (or whatever) harness can just run through 'em all
15:47:26 <wwoods> and that harness should be a standard autoqa test, so it can send its outputs to the standard resultsdb
15:47:37 <adamw> okay, sounds like you agree on a direction to move in
15:47:47 <wwoods> and we can use our standard (future-planned) tools for handling waiving failures &c
15:47:57 <adamw> do we have other topics for open discussion?
15:48:05 <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:12 <wwoods> understood, no problem
15:48:58 * adamw has one if no-one else does =)
15:49:16 <wwoods> I'm tapped out, me
15:49:23 <adamw> okay
15:49:34 <adamw> #topic Open discussion - nss dependency issue
15:49:42 <adamw> so, this was actually suggested by mether
15:50:14 <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:30 <adamw> is everyone broadly aware of the actual issue here?
15:50:40 * jlaska not well versed in this issue, but interested in learning from it
15:51:14 <adamw> well, a quick recap, as I understand it:
15:51:39 <adamw> we have the i686 packages built from 'nss' .src.rpm in the x86-64 repo
15:51:59 <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:52:15 <adamw> now what happened is that an update was issued for nss
15:52:40 <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:41 * nirik notes this is nss-softokn specifically.
15:52:45 <adamw> right, sorry
15:53:27 <wwoods> this sounds like a mash bug?
15:53:30 <nirik> https://admin.fedoraproject.org/updates/nss-softokn-3.12.4-23.fc13
15:53:36 <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:37 <nirik> add karma there and confirm it fixes it.
15:53:51 <adamw> there's various ways to look at it, really
15:54:04 <adamw> it's one of those things where we could strengthen any one bit of the chain and avoid the bug
15:54:38 <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:55:01 <wwoods> right. so why is this a QA issue?
15:55:02 <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:37 <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:50 <wwoods> we aren't responsible for the tools that create the repos, or making decisions about the multilib flag, or the package deps
15:56:24 <wwoods> there are certainly tests we could run that would *detect* this situation and prevent it from getting into the repos
15:56:24 <nirik> I think we might have caught this in updates-testing if critical path had still been enabled.
15:56:24 <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:33 <wwoods> and it's worth making sure that depcheck would catch this
15:56:51 <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:57:46 <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:58:26 <wwoods> so I'm honestly not sure what depcheck would do in that situation
15:58:44 <wwoods> in theory it should do whatever yum did - i.e. barf
15:58:55 <adamw> well, we don't need to answer it right now, just make sure it's on your radar as something to check
15:59:19 <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:38 <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:41 <wwoods> in an email?
16:00:25 <wwoods> or just gimme a link to someone else's explanation of the problem
16:00:50 <adamw> okay, i'll try and find the best explanation to forward
16:00:51 <wwoods> depcheck should prevent this in the future; I'll write a test case to ensure that it properly handles that scenario
16:01:09 <adamw> #action adamw to forward wwoods a good explanation of the nss-softokn problem scenario to ensure autoqa catches it in future
16:01:44 <adamw> well, i guess that's all the juice in that one
16:01:53 <adamw> anything else for open floor, or shall we go eat cookies?
16:02:32 * jlaska notes, no topics from me
16:03:06 <wwoods> I've got one little thing
16:03:22 <wwoods> for the record, a quick summary of how autoqa will handle branched/rawhide
16:04:12 <wwoods> basically: the post-tree-compose hook only triggers for branched, since rawhide doesn't involve boot images
16:04:48 <adamw> #topic Open floor - AutoQA handling branched and rawhide
16:05:16 <wwoods> and also - obviously - bodhi isn't involved in the rawhide workflow
16:05:23 <wwoods> so any testing that we want to do involving rawhide should target either the post-koji-build hook
16:05:27 <wwoods> or the post-repo-update hook
16:05:33 <wwoods> as appropriate to the thing you're trying to test.
16:06:09 <wwoods> once we hit branched, post-tree-compose (and soon post-bodhi-update) will also be viable test hooks
16:06:23 <wwoods> once the release happens, post-tree-compose goes fallow again
16:07:03 <wwoods> I think at this point we've updated the watchers / repoinfo data to handle these things as expected
16:07:27 <adamw> great
16:07:29 <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:32 <wwoods> so that's that.
16:07:40 <adamw> thanks
16:08:16 <jlaska> #action add FIXME links for a wiki page describing the changes, linked from the existing branched SOP pages
16:08:27 <jlaska> #undo
16:08:27 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b7acfd038d0>
16:08:43 <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:09:21 <wwoods> yeah it's pretty straightforward: when we branch, the rawhide tag changes, and some new repos get created.
16:09:30 <wwoods> so we need to edit repoinfo.conf and... change the rawhide tag, and create some new repo entries
16:09:53 <wwoods> makes sense, right?
16:09:57 <jlaska> definitely, thanks!
16:11:48 <adamw> okay, so i think that's all
16:13:10 <adamw> thanks for coming everyone!
16:14:05 <adamw> #endmeeting