11:17 a.m.
I was looking through #258 (https://fedorahosted.org/autoqa/ticket/258)
and have some questions:
Is anyone currently working on this outside the tests that are currently
in the maketest branch?
Are/were there any specific plans for tools? (py.test, unittest, nose,
dingus ...)
Tim
11:47 a.m.
----- Original Message -----
I was looking through #258
(https://fedorahosted.org/autoqa/ticket/258)
and have some questions:
Hello Tim,
Is anyone currently working on this outside the tests that are
currently
in the maketest branch?
Nobody's working on this right now.
Are/were there any specific plans for tools? (py.test, unittest, nose,
dingus ...)
To tell the truth, I have no experience with unittesting in Python
and thus I don't even know the frameworks. If you decide to work
on that, it's your call.
mkrizek originally created a single directory containing unittest
files. But there are also some other tests contained in several
other python files in our project (check out the executable files
and their main methods). I don't know if it is better to execute
them directly, or move the unittest code into the common directory.
Again, depends on your judgement.
Thanks,
Kamil
11:59 p.m.
On 02/01/2011 10:47 AM, Kamil Paral wrote:
> Are/were there any specific plans for tools? (py.test, unittest,
nose,
> dingus ...)
>
To tell the truth, I have no experience with unittesting in Python
and thus I don't even know the frameworks. If you decide to work
on that, it's your call.
mkrizek originally created a single directory containing unittest
files. But there are also some other tests contained in several
other python files in our project (check out the executable files
and their main methods). I don't know if it is better to execute
them directly, or move the unittest code into the common directory.
Again, depends on your judgement.
OK, I have some ideas but I want to make sure that they are appropriate
for AutoQA before I go much farther with them. I'll make a proposal
before I go too far, though.
Do we have any requirements on where AutoQA will run? Specifically, I am
wondering about older versions of Fedora or any version of RHEL. I don't
think that all of the tools I'm thinking of are currently in any
repositories and I don't want to head down that path if it is already a
dead end.
I realize that I would have to package any new tools, have them approved
and at least in rawhide before having a chance of getting anything in
master.
Thanks,
Tim
2:33 a.m.
----- Original Message -----
OK, I have some ideas but I want to make sure that they are
appropriate
for AutoQA before I go much farther with them. I'll make a proposal
before I go too far, though.
Do we have any requirements on where AutoQA will run? Specifically, I
am
wondering about older versions of Fedora or any version of RHEL. I
don't
think that all of the tools I'm thinking of are currently in any
repositories and I don't want to head down that path if it is already
a
dead end.
I realize that I would have to package any new tools, have them
approved
and at least in rawhide before having a chance of getting anything in
master.
Thanks,
Tim
Some of the tools are surely in the repos (mkrizek used nose, it's
in Fedora), some of them might not. I believe our requirement is that
we want to have AutoQA running on RHEL 5+ and supported Fedora's (13+).
Because of RHEL 5.4, we currently limit our server code to Python 2.4
IIRC. But limitation could be soon lifted after we upgrade our production
server to RHEL 6.
But this is really a question for James, let's wait for his reply. It
would be surely best to use packaged tools. If the tool is not packaged
and we need, we should make sure it's possible to have it packaged sooner
or later (we will need to have everything in Fedora in the end).
As for supported RHEL releases (5 and 6 or just 6), I believe James have
some plans for this.
6:26 p.m.
On 02/02/2011 01:33 AM, Kamil Paral wrote:
Some of the tools are surely in the repos (mkrizek used nose, it's
in Fedora), some of them might not. I believe our requirement is that
we want to have AutoQA running on RHEL 5+ and supported Fedora's (13+).
Because of RHEL 5.4, we currently limit our server code to Python 2.4
IIRC. But limitation could be soon lifted after we upgrade our production
server to RHEL 6.
But this is really a question for James, let's wait for his reply. It
would be surely best to use packaged tools. If the tool is not packaged
and we need, we should make sure it's possible to have it packaged sooner
or later (we will need to have everything in Fedora in the end).
As for supported RHEL releases (5 and 6 or just 6), I believe James have
some plans for this.
Thanks for the info, I'll make sure that I'm paying attention to the
EPEL repos for tool versions. I'll make sure to talk to the list before
getting very far on anything, though.
Other than that, we'll see what James' thoughts are on RHEL versions.
Tim
7:37 a.m.
On Wed, 2011-02-02 at 17:26 -0700, Tim Flink wrote:
On 02/02/2011 01:33 AM, Kamil Paral wrote:
>
> Some of the tools are surely in the repos (mkrizek used nose, it's
> in Fedora), some of them might not. I believe our requirement is that
> we want to have AutoQA running on RHEL 5+ and supported Fedora's (13+).
> Because of RHEL 5.4, we currently limit our server code to Python 2.4
> IIRC. But limitation could be soon lifted after we upgrade our production
> server to RHEL 6.
>
> But this is really a question for James, let's wait for his reply. It
> would be surely best to use packaged tools. If the tool is not packaged
> and we need, we should make sure it's possible to have it packaged sooner
> or later (we will need to have everything in Fedora in the end).
>
> As for supported RHEL releases (5 and 6 or just 6), I believe James have
> some plans for this.
Thanks for the info, I'll make sure that I'm paying attention to the
EPEL repos for tool versions. I'll make sure to talk to the list before
getting very far on anything, though.
Other than that, we'll see what James' thoughts are on RHEL versions.
+1 on using existing well established python test frameworks (nose or
unittest). My initial thought is we have enough hassles managing
content that is not yet packaged. I'd like to leverage existing
framework documentation/howto's where possible.
As far as RHEL requirements, nothing comes to mind immediately other
than ensuring python compatibility by way of pylint (or similar). We'll
likely need to maintain a systemd unit, as well as a SystemV initscript.
I'm not sure what unit tests would be required there. I'd like to see
more unit tests for each of the watchers to validate expected outputs
based on a controlled set of inputs. Since they inputs depend on online
services (repodata, koji and bodhi), crafting some known inputs will be
a fun exercise.
Thanks,
James
11:37 a.m.
On 02/07/2011 06:37 AM, James Laska wrote:
on using existing well established python test frameworks (nose or
unittest). My initial thought is we have enough hassles managing
content that is not yet packaged. I'd like to leverage existing
framework documentation/howto's where possible.
Don't worry, I'm not looking to cause too much trouble yet :)
I'm not sure that this discussion is going to be incredibly productive
without examples. I'll be working on that today
As far as RHEL requirements, nothing comes to mind immediately other
than ensuring python compatibility by way of pylint (or similar). We'll
likely need to maintain a systemd unit, as well as a SystemV initscript.
I'm not sure what unit tests would be required there. I'd like to see
more unit tests for each of the watchers to validate expected outputs
based on a controlled set of inputs. Since they inputs depend on online
services (repodata, koji and bodhi), crafting some known inputs will be
a fun exercise.
Yeah, I'm already running into that. I'm trying to figure out how I can
trigger stuff in AutoQA without touching outside services. I have some
ideas but again, not an incredibly productive discussion without examples.
4826
days inactive
4832
days old
autoqa-devel@lists.fedorahosted.org
6 comments
3 participants
participants (3)
-
James Laska -
Kamil Paral -
Tim Flink