16:00:40 <jlaska> #startmeeting Fedora QA Meeting
16:00:40 <zodbot> Meeting started Mon Feb 28 16:00:40 2011 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:45 <jlaska> #meetingtname fedora-qa
16:01:13 <jlaska> #topic Roll call
16:01:19 <jlaska> Hey kanarip
16:01:26 <kanarip> hey jlaska
16:01:26 * jskladan is here
16:01:28 * kanarip here
16:01:29 <jlaska> Anyone else ready for a QA checking?
16:01:32 * red_alert 
16:01:36 <vhumpa> Hey everybody
16:01:39 <kanarip> not really a part of the QA team but regardless ;-)
16:01:41 <jlaska> starting off on the right foot ... "check-in"
16:01:44 * kparal is here
16:01:58 * tflink is present
16:01:59 <adamw> yo
16:02:02 * Alam in
16:02:16 <jlaska> hey all
16:02:31 * vhumpa here
16:02:57 <jlaska> will get started in 30 seconds
16:03:08 <jlaska> who else we waiting for ... robatino, Viking-Ice?
16:03:27 * robatino here
16:03:34 <jlaska> Hey there
16:03:59 <jlaska> I'll be walking through the agenda posted at https://fedoraproject.org/wiki/QA/Meetings/20110228
16:04:17 * Viking-Ice jumps in
16:04:23 <jlaska> alright, let's get movin
16:04:28 <jlaska> #topic Previous meeting follow-up
16:04:40 <jlaska> #info Viking-Ice - solicit feedback on test@lists.fedoraproject.org to see whether we need to require only bugzilla.redhat.com use during test days
16:05:08 <jlaska> Viking-Ice: any updates on your end ... is this something you'd like to continue tracking?
16:06:17 <jlaska> we can come back to that ...
16:06:19 <jlaska> next up ...
16:06:21 <Viking-Ice> jlaska: it's on the agenda
16:06:36 <jlaska> it is?
16:06:50 <Viking-Ice> but let's just get back to it after I post the list and get feed back from the RFE I mentioned to you
16:06:58 <jlaska> okay
16:07:06 <Viking-Ice> jlaska: as in me continue on that topic
16:07:09 <jlaska> #info jlaska - review blocker bug meeting SOP and add include bug summary by way of #info for each bug
16:07:15 <Viking-Ice> the agenda it's on my agenda ;)
16:07:25 <jlaska> no updates from me, I'll look at this sometime this week
16:07:27 <jlaska> Viking-Ice: okay :)
16:08:03 <jlaska> #topic F-15-Alpha RC2 status
16:08:11 <jlaska> adamw: what's the word?
16:08:44 <adamw> yo
16:08:49 <jlaska> #link https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
16:08:50 <adamw> erm, bird?
16:08:55 <jlaska> #link https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
16:08:58 <jlaska> adamw: don't you know about the word?
16:09:11 <adamw> if the word happened during the weekend, hell no.
16:09:13 <jlaska> #info Accepted Alpha blockers - http://bit.ly/f15-alpha-blocker-accepted
16:09:24 <jlaska> #info Proposed Alpha blockers - http://bit.ly/f15-alpha-blocker-proposed
16:09:36 <jlaska> adamw: can you give an update on how things are looking please?
16:09:40 <jlaska> (outside of the links above)
16:09:52 <jlaska> the highlights ... good/bad/ugly
16:09:58 <adamw> rc2 fixes the known blockers we were dealing with last week.
16:10:12 <adamw> given that it was built late friday and i haven't done any real work over the weekend, i don't know much more about it. :)
16:10:24 <adamw> oh, it also fixed two key (for me) nth bugs
16:10:31 <jlaska> splendid
16:10:34 <adamw> the firstboot crash on certain key input bug, and the mesa 32-bit bug
16:10:53 * Viking-Ice only encountered 32 bit bug..
16:11:00 <adamw> we (we being me, toshio and dgilmore) declared the password-echoed-to-screen bug not a blocker based on the difficulty of reproducing it
16:11:03 <jlaska> #info firstboot crash and mesa 32-bit (aka mutter crashing) resolved in RC2
16:11:33 <Viking-Ice> adamw: *cough* and others *cough*
16:11:34 <jlaska> I agree ... shall we move that off the proposed list?
16:11:41 <jlaska> https://bugzilla.redhat.com/show_bug.cgi?id=678720
16:12:16 <Viking-Ice> oh you mean on the bug not the meeting..
16:13:05 <adamw> Viking-Ice: yeah :)
16:13:11 <adamw> jlaska: sure
16:14:02 <jlaska> done ... good, I like to see 2 empty blocker lists
16:14:13 <jlaska> adamw: so what's the plan between now and the go/no_go meeting?
16:14:19 <jlaska> test test and more testing?
16:14:24 <dgilmore> jlaska: i hope so
16:14:27 <jlaska> dgilmore: :)
16:14:35 <adamw> jlaska: yup.
16:14:37 <adamw> test and validate.
16:14:43 <dgilmore> make sure there is no new blockers
16:14:50 <jlaska> do we have a list of bugs that need VERIFIED?
16:14:53 <adamw> given that we didn't change anaconda, i would expect rc2 to wind up good.
16:15:10 <adamw> technically speaking, the only one that needs to be VERIFIED is the gdm bug, i believe
16:15:12 <adamw> er
16:15:15 <adamw> keyboard layout bug
16:15:22 <adamw> since that's the outstanding blocker
16:15:24 <jlaska> okay
16:15:42 <jlaska> note ... thanks to bruno, we have some queries to find UNTESTED blocker bugs
16:16:06 <jlaska> #info List of blocker bugs that were not VERIFIED -- https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Review_CLOSED.2C_but_not_VERIFIED_Blocker_Bugs
16:16:31 <jlaska> okay ... if nothing else, we'll move on to the next topic in 30s
16:17:15 <jlaska> thanks all for testing against the test composes and the RC's ... let's keep getting results in so we can have enough data to support the go/no_go decision
16:17:25 <jlaska> #topic AutoQA update
16:17:44 <jlaska> kparal: What's the latest on the autoqa front?
16:18:12 <kparal> ok, here are the news:
16:18:30 <kparal> #info Our new_koji_watcher was finally pushed to master.
16:18:34 <kparal> Most of the work did jskladan. We also had to solve some issues with missing -pending tags in Koji and Bodhi not correctly marking updates. But lmacken pushed fix recently and therefore everything should be pretty ok now. The new watcher watches for both Koji and Bodhi events and fixes a lot of issues. It also sends "batch" events for tests we can to execute on many events at once.
16:19:02 <jlaska> very nice ... good to see that in master.  Kudos jskladan
16:19:05 <lmacken> I cleaned up all of the stray builds in the pending tags over the weekend as well
16:19:17 <kparal> lmacken: I noticed. thanks for that :-)
16:19:47 <kparal> #info upgradepath was modified to conform to the new batched events type
16:19:54 <kparal> The patch is now waiting in autoqa-devel. We will execute upgradepath on all updates waiting in -pending tag all over and over again, because we currently don't have any means how to re-schedule a test. When we are able to do that, we will change upgradepath to test only the new updates once again.
16:20:37 <jlaska> kparal: can you remind me on the need for rescheduling?
16:21:08 <kparal> jlaska: sure. let's say upgradepath is broken because rawhide contains an old package
16:21:11 <jlaska> this is when we have a FAIL result for one update ... and an update to a newer release resolves the issue
16:21:20 <kparal> then you fix it - push to rawhide most recent version
16:21:29 <kparal> but the failed update won't be re-tested again
16:21:44 <jlaska> I see, thanks
16:22:11 <kparal> ok
16:22:15 <kparal> #info tflink created a new branch 'pytest' containing proof of concept (and even documentation!) of using py.test in autoqa
16:22:32 <tflink> and fixed the shell script, so it should work now
16:22:41 <jlaska> I'm sorry, what is this documentation you speak of? :D
16:22:58 <kparal> :)
16:23:11 <kparal> Great work tflink, testing is largely unknown to me :)
16:23:36 <jlaska> What's the plan for that branch ... is it pending review, and then going into master ... or is more exploration planned?
16:23:36 <kparal> it seems a little complicated, I'll have to study it more. I'm interested in comparing the approaches with standard unittest library
16:23:44 <tflink> thanks, I'm just glad not to have to fight tooth and nail to get working on it
16:23:57 <kparal> I am excited for the most simplest method :-)
16:24:02 <jlaska> +1 :)
16:24:07 <tflink> I'm planning to do another proof of concept using nose/unittest this week
16:24:10 <kparal> jlaska: just proof of concept
16:24:43 <tflink> and update the documentation to reflect that proof of concept and do a comparison between the two tools
16:24:53 <jlaska> nice approach
16:24:57 <wwoods> in anaconda we're using nose
16:25:43 <kparal> I think that covered the last week
16:26:12 <kparal> did I forget some{thing,one}?
16:26:22 <wwoods> there's also an interesting helper module called 'mock' that lets you set up fake versions of real objects and dictate their behavior
16:26:58 <jlaska> hmm ... that sounds interesting for simulating bodhi/koji calls
16:27:00 <kparal> wwoods: tflink introduced dinguses, it's a little confusing but seems interesting concept :)
16:27:01 <wwoods> so you can do unit testing without necessarily needing to set up whole complex environments to run them in
16:27:11 <tflink> wwoods: yeah, I was using Dingus, which is a similar tool.
16:27:18 <wwoods> tflink: interesting, I'll check that out
16:27:27 <wwoods> anyway, thought that might be worth mentioning. also: hi!
16:28:02 <tflink> wwoods: thanks, I'd be interested to see what you think of the proofs of concepts once they're done
16:28:54 <jlaska> kparal: how we looking for doing some more pre builds of 0.4.4?
16:29:37 <kparal> jlaska: well, jskladan has now pushed some patches to depcheck to adjust it for new koji watcher. after that is accepted, I think we can do full build
16:29:55 <wwoods> tflink: sure
16:29:58 <jlaska> excellent ... I'll stay tuned and get ready to build
16:30:12 <jlaska> okay ... anything else to cover for AutoQA?
16:30:27 <kparal> that's all from me
16:30:37 <jlaska> thanks!
16:31:05 <jlaska> okay ... a brief reminder of upcoming events ...
16:31:10 <jlaska> #topic Upcoming QA events
16:31:14 <ianweller> aaaaa
16:31:26 <jlaska> #info Tuesday, March 1 - l10n/i18n Installation Test Day - https://fedoraproject.org/wiki/Test_Day:2011-03-01_L10n_i18n_Installation
16:31:30 <ianweller> whoops
16:31:32 * ianweller hides
16:31:34 <kparal> :))
16:31:34 <jlaska> ianweller: no worries
16:32:16 <jlaska> Igor just recently announced the event ... the wiki looks good and it uses RC2 ... so that's an extra bonus
16:32:31 <adamw> yup, looking nice
16:32:41 <jlaska> #info Wednesday, March 2 - F-15-Alpha - Go/NoGo meeting - https://fedoraproject.org/wiki/Go_No_Go_Meeting
16:32:46 <adamw> it would be really good to get lots of participation in the week
16:33:00 <jlaska> Another go/no_go meeting is planned for this Wednesday
16:33:17 <jlaska> hopefully, not a repeat of last week ... but let's keep testing and stay tuned to the blocker lists posted earlier
16:33:34 <jlaska> #info Thursday, March 3 - i18n Desktop Test Day - https://fedoraproject.org/wiki/Test_Day:2011-03-03_I18n_Desktop
16:33:52 <jlaska> Part#2 of this weeks i18n test days will focus on the desktop
16:34:12 <jlaska> same as before ... good looking wiki and very concise test cases available
16:34:39 <jlaska> any other events folks would like to call attention to?
16:34:48 <jlaska> if not ... we'll move on to a topic I added for robatino
16:35:09 <red_alert> next blocker bug meeting?
16:35:16 <jlaska> red_alert: Wednesday
16:35:41 <jlaska> #topic Infrastructure hosting of delta ISO images
16:35:46 <jlaska> robatino: still there?
16:35:50 <robatino> yes
16:36:06 <jlaska> Hey!  So I added this to the agenda after we spoke on the subject last week
16:36:29 <jlaska> to summarize ... this is to find a more appropriate hosting solution for the delta ISOs you generate?
16:36:53 <robatino> yes - i have space, but it's on crummy infrastructure (not a real HTTP server)
16:36:59 <jlaska> initially, you were thinking about asking for more quota on fedorapeople.org ... and I think this prompted some discussion on whether there might be a more appropriate solution
16:37:33 <robatino> actually, i'd prefer fedorapeople if possible, since it's set up and has the necessary facilities
16:37:51 <jlaska> have you reached out to infrastructure already on this topic?
16:37:54 <robatino> but unfortunately i'd like about 25 G which is much larger than the standard 2G quota
16:38:23 <jlaska> robatino: it would be nice to have a solution where others could help you
16:38:40 <robatino> jlaska: not yet, you suggested i fill out an RFR ( https://fedoraproject.org/wiki/Infrastructure/RFR ) but i need to discuss that with you some more
16:38:49 <jlaska> okay
16:38:57 <jlaska> let's sync up after meeting and we can talk further
16:39:11 <jlaska> if anyone else has ideas or suggestions, feel free to shout
16:39:30 <jlaska> robatino: do you currently have a way to gather download metrics for your delta ISOs?
16:39:57 <robatino> jlaska: adrive does show number of downloads, but i don't know how reliable it is
16:40:03 <jlaska> okay
16:40:22 <kanarip> re
16:40:32 <kanarip> is this topic on hosting delta images for live images as well?
16:40:40 <jlaska> I'm assuming these images are used frequently during testing, since I do see some regular feedback on the list about them
16:40:49 <robatino> kanarip: afaik there's no good delta compression, so no
16:41:00 <robatino> (for live images, i meant)
16:41:21 <kanarip> robatino, right, that's what i wanted to add, it's squashfs that randomizes the bits so much there's no delta
16:41:46 <jlaska> okay, so action here is for robatino & I to continue discussion
16:42:06 <jlaska> robatino: anything else you wanted to add before we move on?
16:42:23 <robatino> not that i can think of
16:42:28 <jlaska> robatino: okay, thanks
16:42:32 <jlaska> #topic FreeIPA v2 Test Day feedback
16:42:43 <jlaska> This is an open topic from last week
16:42:58 <jlaska> dpal had mentioned hosting another FreeIPAv2 test day
16:43:25 <jlaska> which, I don't have any objections to ... but wasn't sure that the challenges listed would be resolved by hosting another event
16:43:39 <jlaska> anyone else have opinions/suggestions here?
16:43:52 <nb> robatino, you need about 25G?
16:43:54 <nb> i'll ask
16:44:03 <nb> i have the capability to grant it, but want to check before giving that large
16:44:08 <jlaska> #info dpal posted challenges/problems encountered from FreeIPA v2 test day -- https://fedorahosted.org/fedora-qa/ticket/163#comment:10
16:44:19 <Viking-Ice> perhaps breaking it up to more test days specific to each part of freeipa would be better
16:44:45 <jlaska> Viking-Ice: so improve the scope?
16:44:50 <jlaska> s/improve/narrow/
16:44:58 <robatino> nb: actually the way that works out is about 10-15G for QA TCs/RCs, about another 10G for Alpha/Beta/Final disos, which would be nice
16:45:04 <robatino> if possible
16:45:18 <Viking-Ice> jlaska:  yup host a directory server test day etc..
16:45:31 <jlaska> adamw: thoughts?
16:46:13 <jlaska> #info Viking-Ice suggested a more narrow scope for the test day (e.g. only directory server)
16:46:26 <jlaska> if nothing else ... we'll move on and track this in the ticket
16:46:31 <Viking-Ice> jlaska: series of each component test day followed by reusing vm images for a final freeipa2 test day?
16:46:58 <jlaska> Viking-Ice: I like the idea, but that's a lot of test days to manage
16:47:18 <Viking-Ice> so?
16:47:20 <Viking-Ice> :)
16:47:29 <jlaska> test days aren't free unfortunately
16:47:34 <jlaska> someone has to prepare and execute them
16:47:46 <Viking-Ice> and :)
16:47:57 <Viking-Ice> get more people involved
16:48:04 <jlaska> sounds like a great idea
16:48:08 <Viking-Ice> hehe :)
16:48:16 <jlaska> this was one of the comments I had in the ticket
16:48:25 <jlaska> feel free to add your suggestions along those lines
16:48:29 <nb> robatino, who all should have access to write?  we're putting it on /pub/alt/stage
16:48:41 <jlaska> would be nice to figure out how to drum up more interest in the subject
16:49:01 <jlaska> alright ... moving on ..
16:49:05 <jlaska> #topic Open discussion - <Your topic here>
16:49:10 <robatino> nb: afaik, just me
16:49:24 <jlaska> any topics folks would like to cover?
16:49:58 <adamw> quick note - i'm sorry not to have followed up on X test week yet
16:50:03 <adamw> got ambushed by the alpha rcs
16:50:21 <adamw> another quick one, we need to go through the CommonBugs list and make sure everything gets documented before Alpha hits
16:50:58 <jlaska> Thanks for reminder ... I wasn't planning to visit those after the go/no_go meeting
16:51:27 <jlaska> #info adamw noted that the X test week recap is delayed, but will be coming to test-announce@ soon
16:53:55 <lmacken> bodhi unit test integration is live
16:54:01 <jlaska> #info Before F-15-Alpha is released, we need to document the current list of CommonBugs -- https://fedoraproject.org/wiki/Common_F15_bugs
16:54:07 <jlaska> anything else on the list
16:54:20 <jlaska> kanarip?
16:54:23 <adamw> lmacken: wahay
16:54:30 <kanarip> here i am
16:54:30 <adamw> lmacken: also the improved comments on bug reports, I noticed
16:54:36 <lmacken> adamw: indeed!
16:54:42 <kanarip> may i fire away?
16:54:48 <kparal> lmacken: any example page?
16:55:07 <lmacken> kparal: I haven't seen any updates that have them yet :(
16:55:15 <kanarip> adamw and i briefly discussed two topics during fudcon in tempe, which i wanted to bring under your attention / consideration
16:55:27 <jlaska> #info lmacken announced that test case integration is now live in bodhi
16:55:40 <jlaska> #undo
16:55:40 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2b025b9b7c90>
16:55:43 <jlaska> #info lmacken announced that wiki test case integration is now live in bodhi
16:55:59 <jlaska> kanarip: okay, what did you have in mind?
16:56:01 <kanarip> one is Continuous Integration, which polls a source code management system for changes and can then build the sources on various platforms, as well as provide test case coverage
16:56:12 <jlaska> ah ... a timely topic :)
16:56:49 <kanarip> i know that many upstream parties just don't have the resources, man-power, and that of course also, fedora project is upstream for a variety of applications
16:57:07 <jlaska> kanarip: autoqa has some support for git post-receive (aka git push) event notification.  We use this to trigger some anaconda tests
16:57:10 <kanarip> i think perhaps package maintainers would also be interested, or at least some of them
16:57:35 <kparal> kanarip: it would be used for fedorahosted projects? or some broader scope?
16:57:46 <tflink> kanarip: you're talking about providing CI for projects, right?
16:58:05 <kanarip> kparal, i'd think some broader scope actually
16:58:24 <kanarip> tflink, yes, fedora project projects and perhaps also upstream "external" projects
16:58:54 <kanarip> i suppose one or the other party interested in getting CI going on their project could trigger the project to be included in the CI environment
16:59:23 <kanarip> like if QA was interested in project X, then QA would request inclusion of project X, but other stakeholders include package maintainers, developers, and such and so forth
16:59:29 <kanarip> i'm hoping it makes sense ;-)
16:59:46 <jlaska> are there projects included in Fedora that already have tests intended for continuous int. execution?
16:59:49 <nb> robatino, can you join #fedora-admin please
17:00:08 <kanarip> jlaska, well, packages for sure; hudson.cyrusimap.org
17:00:11 <adamw> kanarip: what was the example you showed me at fudcon? is it something public?
17:00:12 <tflink> who would maintain the wrapper layer between the CI and non fedorahosted projects
17:00:30 <kanarip> many ruby gem projects also have CI, code coverage, and the likes
17:00:36 * jlaska nods
17:01:01 <kanarip> adamw, the example i showed you is not, but it's hudson.ogd.nl where a customer of mine has CI running for a ruby on rails web app
17:01:09 <jlaska> kanarip: "packages" ?
17:01:21 <jlaska> kanarip: any specific packages, or just package testing in general?
17:01:24 <kanarip> jlaska, applications packaged and included with Fedora
17:01:32 <jlaska> kanarip: that's too broad
17:01:48 <jlaska> kanarip: I think we needed to tighten that up first
17:01:49 <adamw> jlaska: er, i think you're at cross-purposes
17:01:58 <kanarip> jlaska, not the point, you asked whether fedora project internal projects were set up to be used with CI environments
17:02:23 <jlaska> kanarip: hmm, that's a good question too ... but I was thinking of a different topic
17:02:32 <adamw> jlaska: i don't think kanarip was saying 'we should do this for anything that's a package', he was giving a definition of the word 'packages' as he thought you asked for one :)
17:02:35 <kanarip> to which i responded that i didn't know, but i knew for a fact some packages included with fedora do have themselves set up for unit/functional testing, which could be utilized with a ci environment
17:02:45 <jlaska> adamw: gotcha
17:02:58 <jlaska> kanarip: cool, that's good to know
17:03:02 <kanarip> not in so many words though ;-)
17:03:05 <jlaska> heh :)
17:03:18 <jlaska> I'm certainly not opposed to the idea ... who doesn't want more testing :)
17:03:30 <jlaska> Oh I know, the people who like to club baby seals
17:03:35 <kanarip> anyway, perhaps we all ponder on this one a little while...
17:03:52 <kanarip> the other thing i showed off to adamw is testopia as a test case management suite
17:03:53 <tflink> so is the proposal to have CI available to fedorahosted projects? or to set it up for them?
17:03:54 <adamw> are we kind of looking at a way to maybe glue together an example package/project which is set up for CI, and autoqa?
17:04:07 <jlaska> One of the open questions I have are if/how we can intersect this with the goals of autoqa
17:04:18 <jlaska> adamw: bingo
17:04:32 <tflink> I'm not sure that the CI idea isn't orthagonal to autoqa
17:04:37 <jlaska> right
17:04:39 <adamw> tflink: right, that was my question
17:04:45 <tflink> don't get me wrong, I'm all for CI
17:04:50 <adamw> does it make sense to bring it under autoqa or is it something different
17:05:12 <adamw> remembering that i'm probably the dumbest lunk in this particular discussion =)
17:05:13 <jlaska> I think we need to better understand the concept/goals that kanarip is discussing
17:05:16 <tflink> I just tend to think of it as something that is useful for developers instead of the functional integration testing that we tend to do
17:05:53 <kanarip> ci is mostly towards unit testing and code coverage reporting, if you will
17:06:00 <jlaska> we have preliminary support for commit (well git-push) time testing in AutoQA now
17:06:04 <adamw> kanarip: could you maybe write up a detailed proposal (ideally of something with reasonable bounds that make it not a big, scary, open-ended project at first) for the list, with mockups and stuff?
17:06:09 <adamw> or is that too much to ask?
17:06:10 <kanarip> that doesn't make it mutually exclusive with functional testing, but it is something different
17:06:35 <tflink> I'm not articulating incredibly well at the moment, so that isn't helping
17:06:36 <jlaska> yeah ... I think we'll need some vision to start working towards
17:06:37 * adamw trying to think of ways to move the process forward
17:06:41 <kanarip> adamw, i could whip something up, but i can't tell you when it'll be done ;-)
17:06:52 <kanarip> my day only has 24 hours and i'm short another 24 if you will
17:07:09 <jlaska> understood :)
17:07:15 <adamw> kanarip: yeah, i know what you mean :)
17:07:24 <adamw> jlaska: maybe we could task someone to try and work with kanarip on this? tflink?
17:07:29 <kanarip> do we have someone with some developing / continuous integration experience perhaps?
17:07:35 * tflink is interested
17:07:39 <adamw> (sorry, just threw you under the bus there, tim)
17:07:39 <kanarip> awesome
17:07:40 <jlaska> sounds like we have a candidate ;)
17:07:50 <adamw> kanarip: did you get to meet tim at fudcon btw?
17:07:59 <kanarip> not sure, sorry!
17:08:05 <adamw> oh well :)
17:08:09 <tflink> no worries, I'm not sure either :)
17:08:11 <jlaska> kanarip: AutoQA has some *basic* continuous integration support ... but I know tflink understands formal CI better and can help me understand the differences
17:08:27 <kanarip> jlaska, sure, that's cool
17:09:06 <kanarip> i suppose we get a publictest instance up with jenkins and something with autoqa and look how these things fit together exactly, or not at all, and we'll churn out a nice list of bullet points from there
17:09:18 <jlaska> that's one option
17:09:31 <jlaska> should we revisit after you and tflink have had time to discuss?
17:09:34 <kanarip> there's lots of work after the "me like yummie yummie" point either way, so...
17:09:42 <kanarip> yes please
17:09:52 <adamw> awesome.
17:09:59 <kanarip> cool
17:09:59 <tflink> sounds like a plan to me, I'm still trying to understand the scope and integration of the proposal
17:10:05 <kanarip> the other thing then, if we still have some time?
17:10:19 <jlaska> #info kanarip asked about continuous integration.  tflink volunteered to discuss further and the two would return with some ideas on how to proceed
17:10:32 <kanarip> i showed off testopia to adamw for test case management
17:10:44 <jlaska> well, this will be a quick topic :)
17:10:50 <kanarip> it seems it's pretty much covered with mediawikiwiki fu for the moment...
17:10:59 <adamw> duct tape, yes :)
17:11:10 <kanarip> but i was wondering whether testopia has some features that you're interested in
17:11:16 <jlaska> yes and no
17:11:25 <jlaska> we tried *many* releases ago to use testopia
17:11:33 <kanarip> noted of course a major blocker in any testopia case would be the fact that it is bugzilla.*redhat.com* ;-)
17:11:35 <jlaska> and had to stop due to licensing issues with the javascript library used
17:11:49 <jlaska> and some other maint. issues with keeping it in sync with bugzilla HEAD (like we do with bugzilla.redhat.com)
17:11:50 <adamw> i mentioned this to kanarip at the time, but for the meeting, we are already evaluating our needs in a tcms with reference to mediawiki vs. nitrate - http://fedoraproject.org/wiki/Tcms_Comparison
17:11:57 <jlaska> kanarip: https://fedorahosted.org/nitrate
17:12:19 <jlaska> the nitrate project uses the same db schema as testopia but removes the parts that just didn't work for us
17:12:26 <adamw> my takeaway from discussion with kanarip was along the lines of we should consider other candidates and make it a more general comparison; the way rhe has it set up now, this wouldn't be such a change
17:12:29 <jlaska> notably the unusable UI and the license conflict
17:12:32 <kanarip> jlaska, the reason i'm bringing it up is... i'm using it and i'm shipping packages for it, so the maintainance overhead can be very, very low
17:12:34 <adamw> but of course the licensing issue with testopia removes it as a candidate
17:12:53 <adamw> (unless it gets fixed, i guess)
17:13:04 <jlaska> sure ... you can definitely add your feedback to the comparison pages that rhe is maintaining
17:13:14 <kanarip> i'll look into the licensing thing, do we have some reference perhaps?
17:13:19 <jlaska> I'm not overly thrilled about the UI of testopia, it's really really unpleasant
17:13:28 <kanarip> a review request in bugzilla < does anyone know whether it had been udner review?
17:13:40 <jlaska> https://fedoraproject.org/wiki/QA/Testopia_Evaluation
17:13:52 <kanarip> jlaska, agreed, yet again, there's a balance to be sought if not inspiration to be distilled from it ;-)
17:14:00 <jlaska> kanarip: right on
17:14:30 <jlaska> there are other challenges that we'll have with testopia, but we can talk about those later
17:14:34 <kanarip> alright, so that's another quick topic then ;-)
17:14:46 <kanarip> tflink, your fas account name is... tflink?
17:14:54 <tflink> kanarip: yep
17:15:11 <kanarip> then i know your email address... scary huh?
17:15:23 <jlaska> #info kanarip asked whether testopia is being considered - Will integrate his work with https://fedoraproject.org/wiki/Tcms_Comparison
17:15:27 <jlaska> thanks kanarip
17:15:30 <jlaska> okay ... I've got nothing else
17:15:34 <jlaska> and we are 15 mins over
17:15:39 <jlaska> thanks everyone for your time
17:15:45 <jlaska> as always, I'll send minutes to the list
17:15:46 <tflink> well, its not like I hide it much :) If you knew my home address, I'd be more worried
17:15:58 <jlaska> #endmeeting