qa-devel November 2013

qa-devel@lists.fedoraproject.org

8 participants
47 discussions

[Fedora QA] #417: app dependencies are missing in epel6
by fedora-badges 12 Nov '13

12 Nov '13

#417: app dependencies are missing in epel6 --------------------------------------+------------------------ Reporter: tflink | Owner: tflink Type: task | Status: new Priority: major | Milestone: Fedora 20 Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+------------------------ = issue = As we're adding flask-admin in the devel branch, it has unsatisfied dependencies in epel6 ([https://bugzilla.redhat.com/show_bug.cgi?id=991730 rhbz reference]). Those dependencies are: * [http://pkgs.fedoraproject.org/cgit/python-wtf-peewee.git python-wtf- peewee] * [http://pkgs.fedoraproject.org/cgit/python-peewee.git python-peewee] * [http://pkgs.fedoraproject.org/cgit/python-flask-mongoengine.git python- flask-mongoengine] We need to have el6 builds of these deps before we can deploy to -devel and getting everything figured out will help the maintainers of those packages get epel6 builds done more quickly = Task Description = Get all three rpms building in epel6 so we can add them to a side repo and get to testing the upcoming release. It would be best if we fixed the specs the right way and sent patches to each packages' maintainer so that actual epel6 builds can get done sooner. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/417> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 2

Re: [Fedora QA] #316: Indicate bugs that are needinfo
by fedora-badges 12 Nov '13

12 Nov '13

#316: Indicate bugs that are needinfo ---------------------------------------+----------------------- Reporter: adamwill | Owner: mkrizek Type: enhancement | Status: closed Priority: minor | Milestone: Fedora 20 Component: Blocker bug tracker page | Version: Resolution: fixed | Keywords: Blocked By: | Blocking: ---------------------------------------+----------------------- Changes (by mkrizek): * status: new => closed * resolution: => fixed Comment: Fixed and merged in develop [https://git.fedorahosted.org/cgit/blockerbugs.git/commit/?h=develop&id=e0ec… e0ecaf9136a454e5f1690a82b3ab4de0e9531be0] -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/316#comment:5> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 0

Review Request 42: Indicate bugs that are needinfo
by Martin Krizek 12 Nov '13

12 Nov '13

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/42/ ----------------------------------------------------------- Review request for blockerbugs. Bugs: 316 https://fedorahosted.org/fedora-qa/ticket/316 Repository: blockerbugs Description ------- This patch adds a needinfo field into the Bug table. The field is filed with the name of a user that the info is needed from, or empty string if needinfo is not set. If needinfo is set, an icon is displayed in bug list in the same way as the 'recently modified' icon -- any ideas on how to display the information better? Diffs ----- sass/app.scss 061016495d9c46aef0efb5dcfc9e3a5eab43f72c blockerbugs/util/bug_sync.py 49cce49740cd6f5b1f430f58c8d1b522e1f0b7e3 blockerbugs/templates/blocker_list.html 17cdc74d5cac7be3d3843196eeda9e01f1c91ff3 blockerbugs/static/css/app.css 99b6fbc81b231c7f876f1365cfc63f6eade1217e blockerbugs/static/css/app-foundation.css 852272bf1bd1c629b30933b451daceec31812de7 blockerbugs/models/bug.py 095cf7294a5b0a5b3fb9979abf9e669e4acd157c alembic/versions/23cc8daafea8_add_needinfo_to_bug.py PRE-CREATION Diff: http://reviewboard-tflink.rhcloud.com/r/42/diff/ Testing ------- Run db sync, one of the bugs had needinfo flag set, everything worked as expected. Thanks, Martin Krizek

1 14

[Fedora QA] #432: Test day results app should be more navigable: create an event, export results, view all events
by fedora-badges 11 Nov '13

11 Nov '13

#432: Test day results app should be more navigable: create an event, export results, view all events ------------------------------------+----------------------- Reporter: adamwill | Owner: jskladan Type: enhancement | Status: new Priority: major | Milestone: Component: QA tools: test day app | Version: Keywords: | Blocked By: Blocking: | ------------------------------------+----------------------- I find myself having to refer to the Test Day SOP or https://fedoraproject.org/wiki/User:Jskladan/Sandbox:TestdayApp all the time to find the 'magic URLs' to do anything with the test day results app. It's not very internally navigable - you can't find your way from any given part of the UI to the 'new event' or 'export results' or 'view all events' pages, so far as I can tell. It might be nice if there were more internal links, and perhaps if the content from https://fedoraproject.org/wiki/User:Jskladan/Sandbox:TestdayApp were put somewhere more permanent and linked to from within the app itself. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/432> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 4

autoqa rpmlint crashes
by Kamil Paral 05 Nov '13

05 Nov '13

A lot of autoqa rpmlint jobs crash lately. Just to let you know, this is a problem in rpmlint and I reported it here: https://bugzilla.redhat.com/show_bug.cgi?id=1026328

2 1

Requesting/managing upgrades to beaker.fedoraproject.org
by Nick Coghlan 04 Nov '13

04 Nov '13

With Beaker 0.15.1 due out soon, we'd like to upgrade beaker.fedoraproject.org once the new version is available. At the moment, Dan Callaghan and I are admins for the Beaker instance, while Raymond Mancy and Amit Saha are registered users of that instance. However, we aren't admins for the actual *servers*, which is what is needed in order to manage upgrades. We're happy to help manage the Fedora Beaker instance (including upgrades), but when Tim last looked into that, it wasn't easy to give us access to just the Beaker server and lab controllers without giving us broader access to the rest of the Fedora infrastructure systems (which we *don't* really want). I figure the next step is to file a ticket at https://fedorahosted.org/fedora-infrastructure/ but the question is which ticket to file: 1. File a ticket now to get at least Dan and myself (and preferably Ray and Amit as well) sufficient access to handle Beaker upgrades for beaker.fedoraproject.org. 2. Wait until 0.15.1 is available, and then file a ticket to get beaker.fedoraproject.org updated. Regardless of which we do, we should probably create a page on the Fedora wiki and/or a doc in http://infrastructure.fedoraproject.org/infra/docs/ to explain the Fedora Beaker instance's existence and how it gets used, managed and upgraded. Thoughts? Regards, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

2 4

Taskbot: TAP vs Subunit
by Josef Skladanka 04 Nov '13

04 Nov '13

Tim (and of course the rest of the gang ;)), During our chat with Tim, we agreed that we'd really like to use some standardized 'output format' for the tests in Taskbot, to be a bit more programming-language/results-store-implementation agnostic. We knew about two options - TAP <http://testanything.org/wiki/index.php/Main_Page> and Subunit <https://pypi.python.org/pypi/python-subunit>. = Subunit = At least in Python is quite tightly coupled with unittest, both ideologically and practically. I was unable to find a way to just produce a Subunit stream without the need of actually running a testsuite. The format is (basically) just plain PASS/FAIL/INFO/..., and there is possibility to add some 'details'results. It should also be possible to add an attachment to the end of the stream, but no result-specific data can be added (IMO). Also Subunit is now in the process of transition to new implementation, which now should fix some issues with concurrency, add more result-states, etc., but will be binary, so human readability would quite suffer. I do not really feel that this is a good match for our needs (at least without any significant hacking) = TAP = TAP is not unittest-specific, and is human-readable plaintext format. It also has just PASS/FAIL logic, but there is a possibility to add YAML 'metadata' to any result (since TAP v. 13). The real issue with TAP is Python support. There is a TAP-consumer library created as an example for PyParsing <http://pyparsing.wikispaces.com/file/detail/TAP.py>, but it does not support the v13 protocol, and is quite useless as such. TAP-producer library for Python <https://github.com/rjbs/pytap> is also using the old version (i.e. no YAML extensions), and seems to be dead (2 years since last update). It is also quite badly written. = Result = Although neither choice is ideal, I feel that TAP would be the better choice, even though it would mean implementing our own producer/parser. Also the TAP is really simplistic format, so creating a TAP output should be quite easy even in any programming language. It is possible that I somehow utterly misunderstood the Subunit concept, so it might be useful to contact some QAs currently using it (I thing Tim mentioned something about OpenStack?), or contact the developer directly. J.

5 10

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel November 2013