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!
hey, folks - just in case no one spotted it on test@, I have been moonlighting as a python developer lately...
Before you even know it, you'll be a Taskotron developer, finishing it in a fortnight. That's what we're hoping for, anyway.
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.
I spotted it but haven't tried it yet. Sounds great.
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...
I wonder, would it make sense to put it to our "misc" repo, rather than having the projects scattered around the web? I think it would be a good fit. https://git.fedorahosted.org/cgit/fedora-qa.git/
It definitely makes the bookmarking process easier ;)
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 Josef's baby, but I think there wasn't really an intention to revive it for F21 due to so many Fedora.Next and wiki changes. And there was the possibility to use moztrap for F22. But if you think it's viable and helpful to revive testcase_stats, we can have a look at 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 used direct MW API in my stats-{wiki,bugzilla,bodhi} scripts and Josef got inspired by it in testcase_stats. I didn't know about higher level tools like mwclient, that's very helpful information. If we work on it further, I'm all for simplifying it by using a higher-level API.
Which reminds me, we totally failed to collect and send Alpha contributor stats. And the wiki script will probably need adjustments.
i'd be very grateful for your comments / mocking laughter ;) thanks folks!
http://whyfiles.org/wp-content/uploads/2010/03/4.jpg
You're welcome.
On Tue, 2014-10-07 at 06:47 -0400, Josef Skladanka wrote:
Cool stuff, Adam!
where can I submit patches for review? :)
I have kind of a vague plan to deploy gitlab on happyassassin, but it depends on the roundtuits. Adding it to Phabricator as kparal suggested might be a good idea in the mean time / instead.
On Fri, 2014-10-03 at 09:00 -0400, Kamil Paral wrote:
I wonder, would it make sense to put it to our "misc" repo, rather than having the projects scattered around the web? I think it would be a good fit. https://git.fedorahosted.org/cgit/fedora-qa.git/
It definitely makes the bookmarking process easier ;)
It's a lot faster for me on happyassassin, though :P
It might make sense, I'll look into it in a bit.
testcase_stats is Josef's baby, but I think there wasn't really an intention to revive it for F21 due to so many Fedora.Next and wiki changes. And there was the possibility to use moztrap for F22. But if you think it's viable and helpful to revive testcase_stats, we can have a look at it.
I used direct MW API in my stats-{wiki,bugzilla,bodhi} scripts and Josef got inspired by it in testcase_stats. I didn't know about higher level tools like mwclient, that's very helpful information. If we work on it further, I'm all for simplifying it by using a higher-level API.
Which reminds me, we totally failed to collect and send Alpha contributor stats. And the wiki script will probably need adjustments.
wikitcms (relval) now has a web page, releases, and a package repository:
https://www.happyassassin.net/wikitcms/
Today I've been doing some major surgery in a feature branch (this stuff isn't in the packaged version yet, you'll have to check out the branch and run it from the checkout):
https://www.happyassassin.net/cgit/wikitcms/log/?h=wiki-stats
relval can now act as - I believe - a full replacement for stats-wiki, plus Extra Capabilities, and it works for both 21 *and* earlier releases. Try:
relval userstats --release 20 --milestone Final
or:
relval userstats --release 21
or:
relval userstats --release 21 --filter TC --filter RC
wikitcms now has the concept of a 'result object', wiki.find_results() returns a list of the result objects found in a given chunk of wikitext, and 'userstats' is a new relval sub-command that does the work of stats-wiki using these features of wikitcms. There's some fairly ninja list/set comprehension stuff going on there that I TOTALLY DIDN'T RIP FROM STACKOVERFLOW AT ALL OH NO. (Anyone who can manage to do bugs[user] as a single nested comprehension gets many bonus points, because I'm damned if I can). Use of set comprehensions makes the code require python 2.7, but all supported Fedoras have that version, so hey. I've replaced most of kparal's implementation by this point, but the function for producing the HTML-formatted output is mostly untouched (I just changed its inputs a bit), so thanks for that.
I'm reasonably happy with the implementation at this point. So far as I've tested, it replicates the results of stats-wiki.py when called with the same constraints, while offering the additional capability of querying by milestone (and the underlying functions have even more flexibility; you can specify the result statuses to include, and whether 'previous (foo) run'-type results should be included).
I believe it should be relatively simple to re-implement testcase_stats on top of this stuff (I'll look at that tomorrow). I also have a sort-of plan for doing more sophisticated result parsing and adding 'environment' attributes to the result objects; I think it ought to be possible to identify and correctly parse both '2D' and '1D' result tables.
qa-devel@lists.fedoraproject.org
-
Adam Williamson -
Josef Skladanka -
Kamil Paral