Review Request 42: Indicate bugs that are needinfo
by Martin Krizek
-----------------------------------------------------------
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
10 years, 5 months
Requesting/managing upgrades to beaker.fedoraproject.org
by Nick Coghlan
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/)
10 years, 5 months
Taskbot: TAP vs Subunit
by Josef Skladanka
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.
10 years, 5 months
