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
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
= 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 <
: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
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
---
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
>
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
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
+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,
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.)
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
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
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
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
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
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
> *
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
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
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
> >
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
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
>
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
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
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
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
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
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
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
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:
>
+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
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
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
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
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
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
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,
+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
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
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,
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.
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
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:
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.
> >
> >
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
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
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
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
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
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
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
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
- 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
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
* 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
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
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
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 :)
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.
___
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
59 matches
Mail list logo