Re: Check out the Fedora Packager Dashboard!

Björn, I won't be addressing the comments one-by-one, as it mostly boils down to "I don't like the UI/UX" (how I read it, at least). And I absolutely understand and accept that. On the other hand, we (as in the people who developed this) are, well, developers, and that about sums up the UX

Re: orphaning Taskotron-related packages

On Mon, Nov 23, 2020 at 7:11 PM Tim Flink wrote: > > On Thu, 12 Nov 2020 18:25:17 +0100 > Kamil Paral wrote: > > > Note: The email subject should have said "retiring" instead of > > "orphaning". There is little reason to orphan them, retiring is the > > right approach here. Perhaps except for

Re: Fedora Packager Dashboard available for testing

First of all, thanks for the feedback! On Wed, Jun 24, 2020 at 10:28 AM Vít Ondruch wrote: > Would it be possible to change the "reset" to something like "set > all/unset all". When I wanted to know what actually "orphaned" means, I > had to click on every option, which is not very convenient.

Re: Fedora Packager Dashboard available for testing

f them. Why? > > Iñaki > > On Tue, 23 Jun 2020 at 18:35, Josef Skladanka wrote: > > > > Hi, > > > > We'd like to announce public testing of the Packager Dashboard - a new > > service for Fedora package maintainers aiming to provide all relevant > >

Re: Fedora Packager Dashboard available for testing

On Wed, Jun 24, 2020 at 9:15 AM Zbigniew Jędrzejewski-Szmek wrote: > RFE: would it be possible to make the icons in the header clickable > (the part where there's the ladybug, zapf, blocks, wrench, etc), so that > we'd get redirected to that list of issues (e.g. FTI bugs)? It also dawned on me

Re: Fedora Packager Dashboard available for testing

On Wed, Jun 24, 2020 at 9:15 AM Zbigniew Jędrzejewski-Szmek wrote: > RFE: would it be possible to make the icons in the header clickable > (the part where there's the ladybug, zapf, blocks, wrench, etc), so that > we'd get redirected to that list of issues (e.g. FTI bugs)? > > Zbyszek Zbyszek,

Re: Fedora Packager Dashboard available for testing

On Wed, Jun 24, 2020 at 3:16 AM Bob Hepple wrote: > > Nice! > > Is the ourobolos (the snake eating its own tail) supposed to animate > all the time? To me, that kinda sorta means something is working - but > what? Hovering over it gives no clue. > > Or should I just wait a bit longer for it to

Fedora Packager Dashboard available for testing

Hi, We'd like to announce public testing of the Packager Dashboard - a new service for Fedora package maintainers aiming to provide all relevant data: FTBFS/FTI status (from both Bugzilla, Koschei and health check), orphan warnings, bugzillas, pull requests, active overrides and updates - at a

Re: Change proposal discussion - Optimize SquashFS Size

On Thu, Feb 6, 2020 at 3:06 PM Kevin Kofler wrote: > Hence, the remainder of your post is a strawman based on entirely > fictional > "statistics". > > I'm glad you agree that your own argumentation is flawed, since it's based entirely on fictional statistics :) Since you not only presented no

Re: Change proposal discussion - Optimize SquashFS Size

On Thu, Feb 6, 2020 at 12:01 AM Kevin Kofler wrote: > Oh, and to answer your other point: > > Lukas Brabec wrote: > > It is pretty common for us in Fedora QA (well, I'm quite biased in this > > case). > > And no, we cannot compose our images, we have to test the exact same > > images that will

Re: [Test-Announce] Fedora 29 Final is GO

On Fri, Oct 26, 2018 at 11:02 PM Christian Dersch wrote: > > Having that criterion " if there's an RC specific failure to output images > that didn't cause nightlies to fail, then we have to find out what's going > on." would be really nice. > > Greetings, > Christian > Christian, I absolutely

Re: status report

Sorry, wrong list. I blame the heat! On Sun, Jun 10, 2018 at 5:19 PM, Josef Skladanka wrote: > = Highlights = > > * Participated in interviewing candidates to replace Petr > * Deployed Vault on dev > * there still are some quirks with OIDC login, that I need to iron out, &g

status report

= Highlights = * Participated in interviewing candidates to replace Petr * Deployed Vault on dev * there still are some quirks with OIDC login, that I need to iron out, but the overall concept seems good for the usecase * Modified libtaskotron to allow grabbing secrets from the Vault <

Re: Please review - Infra Ansible - move slaves from home to srv

:03 +0100 > Josef Skladanka <jskla...@redhat.com> wrote: > > > I'm not sure what is the best way to ask for review for a pagure-less > > project, since we don't use Phabricator any more, so... let the > > funmail begin: > > The wrapped diff is hard to read but it look

Please review - Infra Ansible - move slaves from home to srv

I'm not sure what is the best way to ask for review for a pagure-less project, since we don't use Phabricator any more, so... let the funmail begin: diff --git a/inventory/host_vars/qa10.qa.fedoraproject.org b/inventory/host_vars/qa10.qa.fedoraproject.org index 297f614e3..d2119dc47 100644 ---

Re: 2017-10-16 @ 14:00 UTC - Fedora QA Devel Meeting

Looks like it will be just the two of us today, Tim - I don't have any serious updates, but I'm all for doing it, if you deem it useful. On Mon, Oct 16, 2017 at 6:36 AM, Tim Flink wrote: > # Fedora QA Devel Meeting > # Date: 2017-10-16 > # Time: 14:00 UTC >

Re: Proposal to CANCEL: 2017-08-28 QA Devel Meeting

ack On Mon, Aug 28, 2017 at 5:58 AM, Tim Flink wrote: > There are more than one of us traveling to Flock on Monday and as such, > I propose that we cancel the regularly scheduled QA Devel meeting. > > If there is some urgent topic to discuss, please reply to this thread > and

Discontinuing Phabricator

As you all probably know, we decided that keeping Phab up and running is not the best use of our - rather limited, and shrinking - resources, so we moved all our projects to Pagure. Yay! As of now, all (relevant) tickes are moved to Pagure, and we have the Differential revisions archived as html

Re: Proposal to CANCEL: 2017-07-03 QA Devel Meeting

+1 On Sat, Jul 1, 2017 at 7:30 PM, Tim Flink wrote: > There are multiple holidays this week and I suspect that most folks > (including me) won't be around for a QA Devel meeting so I propose that > we cancel the regular meeting. > > If there is some urgent topic to discuss,

Re: Re-Scheduling Jobs for Taskotron as a User

On Thu, Apr 20, 2017 at 12:07 AM, Adam Williamson < adamw...@fedoraproject.org> wrote: > OK, like I said, half-baked =) But wdyt? > > Love it! (And I swear, it has nothing to do with the fact, that I also thought this would be a great way to solve it in a more generic manner.)

Re: Proposal to CANCEL: 2017-03-27 QA Devel Meeting

OK On Mon, Mar 27, 2017 at 5:30 AM, Tim Flink wrote: > I have a conflict during the normal QA Devel meeting this week so > unless someone else wants to lead the meeting, I propose that we cancel > it. > > Tim > > ___ > qa-devel

Trigger changes - call for comments

Hey, gang! As with the ExecDB, I took some time to try and formalize what I think is to be done with Trigger in the near-ish future. Since it came to my attention, that the internal G-Docs can not be accessed outside of RH, this time, it is shared from my personal account - hopefully more people

Re: Taskotron CI in Taskotron

On Wed, Feb 15, 2017 at 5:55 PM, Adam Williamson <adamw...@fedoraproject.org > wrote: > On Wed, 2017-02-15 at 12:59 +0100, Josef Skladanka wrote: > > On Tue, Feb 14, 2017 at 8:51 PM, Adam Williamson < > adamw...@fedoraproject.org > > > wrote: > > > Are you a

Re: Taskotron CI in Taskotron

On Tue, Feb 14, 2017 at 8:51 PM, Adam Williamson wrote: > Are you aware of fedmsg-dg-replay? It's a fairly easy way to 'replay' > fedmsgs for testing. All you need (IIRC) is the fedmsg-relay service > running on the same system, and you can run > I am, but it has

ExecDB rewrite - call for comments

Hey gang! With the incoming changes, I'd like to make ExecDB a bit more worth its name, and make it less tied to Buildbot than it is at the moment, and also make some changes to what functionality it provides. Please, comment! Thanks, Joza

Re: Wiki page gardening

Awesome, thanks! On Fri, Feb 10, 2017 at 4:27 AM, Adam Williamson wrote: > Hi folks! I did a bit of light gardening on the Taskotron and ResultsDB > and a few other wiki pages today: > > * https://fedoraproject.org/wiki/Taskotron > *

Re: Taskotron CI in Taskotron

On Thu, Feb 9, 2017 at 5:58 PM, Matthew Miller <mat...@fedoraproject.org> wrote: > On Thu, Feb 09, 2017 at 03:29:13AM +0100, Josef Skladanka wrote: > > I finally got some work done on the CI task for Taskotron in Taskotron. > The > > idea here is that after each commi

Taskotron CI in Taskotron

Gang, I finally got some work done on the CI task for Taskotron in Taskotron. The idea here is that after each commit (of a relevant project - trigger, execdb, resultsdb, libtaskotron) to pagure, we will run the whole stack in docker containers, and execute a known "phony" task, to see whether it

Re: Libtaskotron - allow non-cli data input

On Wed, Feb 8, 2017 at 7:39 PM, Kamil Paral wrote: > > I mentioned this in IRC but why not have a bit of both and allow input > > as either a file or on the CLI. I don't think that json would be too > > bad to type on the command line as an option for when you're running > >

Re: Libtaskotron - allow non-cli data input

On Wed, Feb 8, 2017 at 4:11 PM, Tim Flink wrote: > On Wed, 8 Feb 2017 08:26:30 -0500 (EST) > Kamil Paral wrote: > > I think another question is whether we want to keep assuming that the > *user supplies the item* that is used as a UID in resultsdb. As you

Re: Libtaskotron - allow non-cli data input

On Wed, Feb 8, 2017 at 2:26 PM, Kamil Paral wrote: > This is what I meant - keeping item as is, but being able to pass another > structure to the formula, which can then be used from it. I'd still like to > keep the item to a single string, so it can be queried easily in the >

Re: Libtaskotron - allow non-cli data input

On Mon, Feb 6, 2017 at 6:49 PM, Kamil Paral wrote: > The formulas already provide a way to 'query' structured data via the > dot-format, so we could do with as much as passing some variable like > 'task_data' that would contain the parsed json/yaml. > > > Or are you proposing

Re: Lift type-restriction on ibtaskotron's cli + resultsdb directive

On Mon, Feb 6, 2017 at 6:19 PM, Kamil Paral wrote: So this is about removing `_ITEM_TYPES` from `main.py`, correct? > Yes, I could have been more specific. > > I don't have a problem with that, as long as any relevant docs are updated > and we're able to present a reasonable

Re: making test suites work the same way

On Mon, Feb 6, 2017 at 1:35 PM, Kamil Paral wrote: > > That's a good point. But do we have a good alternative here? If we depend > on packages like that, I see only two options: > > a) ask the person to install pyfoo as an RPM (in readme) > b) ask the person to install gcc and

Libtaskotron - allow non-cli data input

Chaps, we were discussing this many times in the past, and as with the type-restriction, I think this is the right time to get this done, actually. It sure ties to the fact, that I'm trying to put together Taskotron-continuously-testing-Taskotron together - the idea here being that on each

Lift type-restriction on ibtaskotron's cli + resultsdb directive

Hey Gang, this is bugging me for quite a while now, and although I know why we put the restrictions there back then, I'm not sure the benefits still outweigh the problems. Especially now, when we'll probably be getting some traction, I'd like to propose removing the type-check completely. On top

Re: ResultsDB 2.0 - DB migration on DEV

Estimate on the PROD migration finish is in about 24 hours from now. STG was seamless, so I'm not expecting any troubles here either. On Wed, Jan 25, 2017 at 10:47 AM, Josef Skladanka <jskla...@redhat.com> wrote: > STG is done (took about 15 hours), starting the archive migration f

Static dashboards PoC

Folks, lbrabec and I made the static dashboards happen, a sample can be seen here: https://jskladan.fedorapeople.org/dashboards/ Note that these are all generated from a yaml config that defines the packages/testcases + real resultsdb data. Not that the dashboards make much sense, but it shows

Re: ResultsDB 2.0 - DB migration on DEV

So I started the data migration for the STG archives - should be done in about 15 hours from now (running for cca six hours already) - estimated on the number of results that were already converted. If that goes well, I'll start the PROD archives migration tomorrow, and start working on merging

Re: ResultsDB 2.0 - DB migration on DEV

Just for the sake of logging things done, this is how pruning the PROD db was done - it is conceptually the same as what was done for STG, so I'm not adding the comments. $ pg_dump -Fc resultsdb > resultsdb.dump $ createdb -T template0 resultsdb_archive $ pg_restore -d resultsdb_archive

Re: Proposal: Migrating More Git Projects to Pagure

On Fri, Jan 13, 2017 at 5:49 PM, Adam Williamson <adamw...@fedoraproject.org > wrote: > On Fri, 2017-01-13 at 14:16 +0100, Josef Skladanka wrote: > > > I am personaly against issues/pull requests on Pagure - logging into > Phab > > is about as difficult as logging i

Re: New ExecDB

on removing the tight coupling between execdb and buildbot, and then I went on trying to figure out what's in this thread. On Tue, Jan 10, 2017 at 6:57 AM, Tim Flink <tfl...@redhat.com> wrote: > On Fri, 21 Oct 2016 13:16:04 +0200 > Josef Skladanka <jskla...@redhat.com> wrote: >

Re: Proposal to CANCEL: 2016-12-19 Fedora QA Devel Meeting

+1, especially since all the relevant pepole here are on PTO. On Mon, Dec 19, 2016 at 5:34 AM, Tim Flink wrote: > Most of the regular folks will be absent this week and I'm not aware of > anything urgent to cover so I propose that we cancel the weekly Fedora > QA devel

Re: ResultsDB 2.0 - DB migration on DEV

On Mon, Dec 5, 2016 at 4:25 PM, Tim Flink wrote: > Is there a way we could export the results as a json file or something > similar? If there is (or if it could be added without too much > trouble), we would have multiple options: > Sure, adding some kind of export should be

Re: Release validation NG: planning thoughts

On Thu, Dec 1, 2016 at 6:04 PM, Adam Williamson <adamw...@fedoraproject.org> wrote: > On Thu, 2016-12-01 at 14:25 +0100, Josef Skladanka wrote: > > On Wed, Nov 30, 2016 at 6:29 PM, Adam Williamson < > adamw...@fedoraproject.org > > > wrote: > > > On Wed, 201

Re: Release validation NG: planning thoughts

On Wed, Nov 30, 2016 at 6:29 PM, Adam Williamson <adamw...@fedoraproject.org > wrote: > On Wed, 2016-11-30 at 18:20 +0100, Josef Skladanka wrote: > > I would try not to go the third way, because that is really prone to > erros > > IMO, and I'm not sure that "per

Re: Release validation NG: planning thoughts

On Wed, Nov 30, 2016 at 11:10 AM, Adam Williamson < adamw...@fedoraproject.org> wrote: > On Wed, 2016-11-30 at 09:38 +0100, Josef Skladanka wrote: > > So if this is what you wanted to do (data validation), it might be a good > > idea to have that submitter middleware. > &g

Re: Release validation NG: planning thoughts

On Tue, Nov 29, 2016 at 5:34 PM, Adam Williamson wrote: > On Tue, 2016-11-29 at 19:41 +0530, Kanika Murarka wrote: > > 2. Keep a record of no. of validation test done by a tester and highlight > > it once he login. A badge is being prepared for no. of validation

Re: Release validation NG: planning thoughts

On Mon, Nov 28, 2016 at 6:48 PM, Adam Williamson wrote: > On Mon, 2016-11-28 at 09:40 -0800, Adam Williamson wrote: > > The validator/submitter component would be responsible for watching out > > for new composes and keeping track of tests and 'test environments' (if

ResultsDB 2.0 - DB migration on DEV

So, I have performed the migration on DEV - there were some problems with it going out of memory, so I had to tweak it a bit (please have a look at D1059, that is what I ended up using by hot-fixing on DEV). There still is a slight problem, though - the migration of DEV took about 12 hours total,

Re: Proposal to CANCEL: 2016-10-31 Fedora QA Devel Meeting

+1 to cancel On Mon, Oct 31, 2016 at 5:58 AM, Tim Flink wrote: > I'm not aware of any topics that need to be discussed/reviewed as a > group this week, so I propose that we cancel the weekly Fedora QA devel > meeting. > > If there are any topics that I'm forgetting about

Re: New ExecDB

So, after a long discussion, we arrived to this solution. We will clearly split up the "who to notify" part, and "should we re-schedule" part of the proposal. The party to notify will be stored in the `notify` field, with `taskotron, task, unknown` options. Initially any crashes in `shell` or

Re: New ExecDB

On Tue, Oct 11, 2016 at 1:14 PM, Kamil Paral wrote: > Proposal looks good to me, I don't have any strong objections. > > 1. If you don't like blame: UNIVERSE, why not use blame: TESTBENCH? > 2. I think that having enum values in details in crash structure would be > better,

Re: Resultsdb v2.0 - API docs

So, what's the decision? I know I can "guesstimate", but I'd like to see a group consensus before I actually start coding. On Thu, Sep 29, 2016 at 7:31 AM, Josef Skladanka <jskla...@redhat.com> wrote: > > > On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral <kpa...@redhat.

Re: Resultsdb v2.0 - API docs

On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral wrote: > ... > What are the use cases? I can think of one - yesterday Adam mentioned he > would like to save manual test results into resultsdb (using a frontend). > That would have no ExecDB entry (no UUID). Is that a problem in

Re: 2016-09-14 @ 14:00 UTC - QA Tools Video "Standup" Meeting

I'd rather go with the option no. 1, but I don't really care that much either way. So if one option suits you guys better, I'll comply. J. On Thu, Sep 22, 2016 at 9:59 AM, Martin Krizek wrote: > - Original Message - > > From: "Tim Flink" > > To:

Re: RFR: New Dist-Git Task Storage Proposal

On Tue, Sep 13, 2016 at 4:20 PM, Tim Flink wrote: > On Mon, 12 Sep 2016 14:44:27 -0600 > Tim Flink wrote: > > > I wrote up a quick draft of the new dist-git task storage proposal > > that was discussed in Brno after Flock. > > > >

Re: Resultsdb v2.0 - API docs

On Tue, Sep 13, 2016 at 8:19 PM, Randy Barlow wrote: > Will the api/v1.0/ endpoint continue to function as-is for a while, to > give integrators time to adjust to the new API? That would be ideal for > Bodhi, so we can adjust our code to work with v2.0 after it is

Re: Resultsdb v2.0 - API docs

be stable (or at least a base for non-breaking changes) for at least next few years (lol I know, right...), so let's do it right :) joza On Mon, Aug 15, 2016 at 10:48 PM, Josef Skladanka <jskla...@redhat.com> wrote: > Hey gang, > > I spent most of today working on the new API docs fo

Resultsdb v2.0 - API docs

Hey gang, I spent most of today working on the new API docs for ResultsDB, making use of the even better Apiary.io tool. Before I put even more hours into it, please let me know, whether you think it's fine at all - I'm yet to find a better tool for describing APIs, so I'm definitely biased, but

Re: Request for Testing: New Auth Method for Phabricator

Linking the account worked for me just fine, although I stumbled upon the Err 500 while trying to log-in via persona (worked on the second try, though). After logging out, and re-logging in via Ipsilon for the first and third time, this is what I got: Unhandled Exception

PoC of "configurable trigger"

Source: https://bitbucket.org/fedoraqa/taskotron-trigger/branch/pony Diff: https://phab.qadevel.cloud.fedoraproject.org/D872 This started as simple bike-shedding to make more sense in naming (so everything is not named "Trigger"), but it went further :D The main change here is, what I call

Re: 2016-05-09 @ 14:00 UTC - Fedora QA Devel Meeting

Won't be able to make it today, but I spent the last two weeks dealing with base-image building. I can use some tasks, if we have something urgent and doable. Otherwise, I'd continue hacking on the trigger. On Mon, May 9, 2016 at 6:02 AM, Tim Flink wrote: > # Fedora QA Devel

Re: Proposal to CANCEL: 2016-03-21 Fedora QA Devel Meeting

ack On Mon, Mar 21, 2016 at 6:47 AM, Tim Flink wrote: > I don't have any hugely important topics for the QA Devel meeting this > week so instead of taking up 30-60 minutes of everyone's time this > week, I propose that the meeting be canceled. > > If there is a topic that you

Testcase namespacing - adding structure to result reporting

This is an initial take on stuff that was discussed in person during Tim's stay in Brno. Sending to the list for additional discussion/fine-tuning. = What = Talking rpmgrill-like checks, there will be a need to be able to facilitate some kind of structure for representing that a check is

Re: 2015-07-27 @ 14:00 UTC - Fedora QA Devel Meeting

I won't be able to make it to the meeting today, so please just CP these: #topic jskladan's update #info T414 is cursed /me spent most of the week getting distracted by OtherThings(tm) #info Docker is broken (machines can't be linked) - BUG #1244124 #info when `git apply` is misbehaving, check

Re: Coding Style

- Original Message - From: Kamil Paral kpa...@redhat.com Will we try to live with it in libtaskotron for a while, or should I create similar patches for all our projects right away? I vote for doing it everywhere. I have already converted the ExecDB using autopep8 `autopep8 -r

Re: Coding Style

I'm not picking on Josef here - I'm sure I've submitted code recently with lint errors, this was just the review I was looking at which triggered the idea: https://phab.qadevel.cloud.fedoraproject.org/D389 No worries, I'm not taking it personaly. As I commented in the D389 - the

Re: 2015-06-01 Fedora QA Devel Meeting Minutes

* tflink to pester jskladan Sorry about that, /me misread some old let's cancel the meeting email... ad Testdays: The Testday revamp is about half-done, as the process was interrupted by testing spree. I'm all in for 'killing' the old cloud machine, and I think it can be done ASAP. The

Re: openQA live image testing: ready for merge?

Adam, please set these up for review in Phabricator. I strongly suspect (given the time that I spent looking at the changes so far) that some discussion will be required, and Phab is _the_ place to do it. Also, please make sure to rebase your repos to their current state, before creating the

Re: openQA live image testing: ready for merge?

Some preliminary feedback: = openqa_fedora = == _do_install_and_reboot.pm == Please delete the anaconda_install_finish needle, if it is unused. anaconda_install_done needle: * Why is only a part of the button selected? * What is the logic behind assert_and_click for multiple areas in one

Re: Coding Style

But if there's a strong desire for more columns, I'll manage. Can't hinder the team, can I? :) Also, we should mention that by default the maximal line length is set to 79, not 80. Let's just set it to 80 (as we already use it in the code), and forget about the heretic 100 idea :)

Re: Default invocation of pytest for qadevel projects

Any thoughts on which of those (if either) would be better? I do not really mind either, and do not have any strong preference. I'm used to having the non-functional tests run by default, but I can easily manage any way we decide to do it. j. ___

Taskbot: TAP vs Subunit

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

Re: Taskbot: TAP vs Subunit

Lucas, do you use any library for producing TAP format? Also, do you have any TAP parser, or do you just emit it? I was looking for something in Python, but all I got is either outdated, or non-complete. Thanks, Joza ___ qa-devel mailing list