qa-devel October 2014

qa-devel@lists.fedoraproject.org

8 participants
14 discussions

testcase-stats on wikitcms PoC
by Adam Williamson 12 Oct '14

12 Oct '14

Hey, folks. Today I got a PoC of testcase-stats on top of wikitcms up and running. It's not complete yet as I haven't written the bits to provide the CLI and page selection stuff, but all the hard stuff is there. I'm attaching it. To test it, just stick it in the stats/testcase-stats directory of a fedora-qa git checkout, symlink an up-to-date checkout of the wikitcms 'results-types' branch into the same directory, and run it. It'll output to /tmp/tcstats_test , but you can easily change that if you like. You can also change the hard-coded list of pages it runs on. Tomorrow I'll aim to clean it all up and make it a relval sub-command, then maybe release wikitcms 2.0. it may get interesting when I look at feeding in various possible groups of pages, but I'll burn that bridge when I come to it. The contortions this goes through to wrangle the data into the correct forms seem slightly inelegant, but I don't see any easy significant wins in simplifying them - thoughts welcome. What it does is roughly this: * Get a list of ResultRow objects for each page in the page set * make a dict of lists of tuples (!). the keys are tuples for all the 'unique tests' for which at least one ResultRow exists, where a 'unique test' is the combination of testcase + 'test name' - when you have something like [[QA:Testcase_default_boot_install|Workstation live]], QA:Testcase_default_boot_install is the testcase and "Workstation live" is the 'test name'. the value tuples are the ResultRows for that 'unique test'; field 0 is a string identifying the compose from which the ResultRow comes (e.g. 'BetaTC1'), field 1 is the ResultRow object itself. we need to keep the rows for each compose for each 'unique test' separate. * make another dict, using the same keys from the last one, with the value for each key being a Test() object instantiated from the list of tuples from the first test case. That class can now produce all the information the HTML rendering functions need to do their stuff. if anyone sees a way to simplify that while still making it possible for the renderers to get all the data they need fairly simply, please do enlighten me =) one possible thing we could do is let wikitcms provide milestone / compose properties for resultrow objects, that might help. I'll have to look at it tomorrow. If I was writing this from scratch maybe I'd go about it slightly differently, but I don't think the ugliness is sufficient to merit burning down all josef's work and starting over. it works fine. the actual rendering functions are more or less intact from josef's version, I just adjusted them to consume the data from the Test() objects. the Test() classes' __init__() is pretty much ripped from josef's version too. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 1

relval progress report
by Adam Williamson 08 Oct '14

08 Oct '14

hey, folks - just in case no one spotted it on test@, I have been moonlighting as a python developer lately... https://www.happyassassin.net/cgit/relval/ is a little thing I'm writing with the initial goal of making the process of kicking off a release validation event easy. In the true tradition of software projects, it already has a hopelessly confused naming history: it's now officially the module 'wikitcms' with the command line tool 'relval', but I didn't get around to renaming the repository yet... right now it'll create the validation result pages for an event, and handle categories: it deals with the limitation in the magic template system that results in pages being in the wrong category, and makes sure the whole hierarchy of categories up to Test_Results is correct (per the SOP) each time you create an event. I'm trying to write it in such a way as to be reasonably extensible and re-usable, with an eye to making it do more later. I just had a quick look, and I think it may be possible to either fold testcase_stats into it, or rewrite testcase_stats to use it as a backend for at least some stuff and simplify it. testcase_stats is written to do MW API calls itself, which it doesn't really need to do, it could use mwclient as relval/wikitcms does, and it can probably use some of wikitcms' knowledge of what pages should exist for what events and so on. I do mean to add a property of ComposeEvent() which would be the result pages that currently actually exist for that event. i'd be very grateful for your comments / mocking laughter ;) thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

3 4

2014-10-06 QA Devel Meeting Minutes
by Tim Flink 06 Oct '14

06 Oct '14

========================== #fedora-meeting-1: qadevel ========================== Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-10-06/qadevel.2014-1… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2014-10-06/qadevel.2014-1… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-10-06/qadevel.2014-1… Meeting summary --------------- * welcome (tflink, 14:03:03) * iteration 6 status (tflink, 14:08:18) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T322 (tflink, 14:08:55) * ACTION: tflink to get status update on depcheck enhancements from handsome_pirate (tflink, 14:25:03) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T333 (mkrizek, 14:28:23) * next iteration (tflink, 14:31:02) * ACTION: tflink to update production phab (tflink, 14:33:33) * will extend iteration 6 for 2 more weeks instead of closing it out - freeze starts next week and a new iteration would mean a lot of ticket churn (tflink, 14:36:12) * open floor (tflink, 14:39:11) Meeting ended at 14:40:56 UTC. Action Items ------------ * tflink to get status update on depcheck enhancements from handsome_pirate * tflink to update production phab Action Items, by person ----------------------- * tflink * tflink to get status update on depcheck enhancements from handsome_pirate * tflink to update production phab * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * tflink (55) * kparal (41) * mkrizek (9) * zodbot (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

[Fedocal] Reminder meeting : Fedora QA Devel Meeting
by Kamil Páral 05 Oct '14

05 Oct '14

Dear all, You are kindly invited to the meeting: Fedora QA Devel Meeting on 2014-10-06 from 10:00:00 to 11:00:00 America/New_York At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Biweekly meeting to go over QA development related topics (Taskotron, BlockerBugs, and other tools). Specific agendas are sent out on [test][1] and [qa-devel][2] lists. **Join us at #fedora-meeting-1 on irc.freenode.net** (For help with IRC, please read [IRC help page][3]). Meeting logs can be read in the [meetbot archive][4]. [1]: https://lists.fedoraproject.org/mailman/listinfo/test-announce [2]: https://lists.fedoraproject.org/mailman/listinfo/qa-devel [3]: https://fedoraproject.org/wiki/How_to_use_IRC [4]: http://meetbot.fedoraproject.org/teams/fedora-qa-devel/ Source: https://apps.fedoraproject.org/calendar//meeting/785/

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel October 2014