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
----- 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
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
----- 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.
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
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
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.
autoqa-devel@lists.fedorahosted.org