diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20130104/182edc02')
| -rw-r--r-- | zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment-0001.html | 8 | ||||
| -rw-r--r-- | zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment.html | 8 |
2 files changed, 16 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment-0001.html new file mode 100644 index 000000000..8ce2835ed --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment-0001.html @@ -0,0 +1,8 @@ +<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>I've already posted this to the Mageia forum, but doktor5000 suggested to also post this to the mailing list.</div><div><br></div><div>I'd like to ask if it would make sense for Mageia to automatically test generated RPM packages. The idea isn't new. Ubuntu is using regression tests with python-unit for a lot of packages in their distribution: <a href="https://wiki.ubuntu.com/MeetingLogs/devweek0909/RegressionTests">https://wiki.ubuntu.com/MeetingLogs/devweek0909/RegressionTests</a></div> +<div><br></div><div>I think that using automated regession tests would make the job of QA a lot easier. Failures within packages would surface much faster and a lot of manual checking could be avoided. Don't get me wrong. Every package that would pass the regression tests should still be checked by a human. ;)</div> +<div><br></div><div>The following scenario could be used for this. After the package hast been generated, the RPM (or job) is passed to the regession test server. This server spawns a new virtual machine with the Mageia version the package should be checked on. When the machine is booted, the package is installed with all the needed dependencies and the tests are executed. If everyting went smooth, the package might be checked again by QA manually. If one or more tests failed, there is something wrong with package, although the package generation worked, and the maintainer/developer might want to take a look at it again.</div> +<div><br></div><div>To setup this up a combination of hudson (<a href="http://hudson-ci.org">hudson-ci.org</a>) and vagrant (<a href="http://vagrantup.com">vagrantup.com</a>) could be used. vagrant allows to use VirtualBox to boot serveral VM instances from base images that are thrown away after everything is done. This way multiple versions of Mageia could be tested on one well equipped server. One drawback with VirtualBox would be the missing ARM support.</div> +<div><br></div><div>Let's use something like a JSON lib for Python as an example. The package generation was successful. But Python is a highly dynamic language, so some submodule is missing due to a wrong install path, although "import json-xy" of the main module works flawlessly. Without further testing this will only surface when a poor developer uses the submodule or when a second package that depends on that submodule is tested by QA and shows errors or misbehaviours.</div> +<div>Second example, same lib. The JSON lib usually ships with a handy executable to lint check JSON files, but upstream decided to change that. Due to an error in the upstream repo, the executable script file is still there but it's empty or there is gibberish in it. There is no more lint checking possible with this executable. Automatic testing would show this very fast and without someone sitting there, pasting some JSON into a file to feed the executable with it.</div> +<div><br></div><div>Testing UI would be an other story, but I guess you get the idea. ;-)</div><div><br></div><div>That do you think about that? I think it would enhance the quality on Mageia in the long run and take some work from QA to find the really tricky bugs.</div> +<div><br></div><div>Regards,</div><div><br></div><div>Jochen</div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment.html b/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment.html new file mode 100644 index 000000000..8ce2835ed --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment.html @@ -0,0 +1,8 @@ +<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>I've already posted this to the Mageia forum, but doktor5000 suggested to also post this to the mailing list.</div><div><br></div><div>I'd like to ask if it would make sense for Mageia to automatically test generated RPM packages. The idea isn't new. Ubuntu is using regression tests with python-unit for a lot of packages in their distribution: <a href="https://wiki.ubuntu.com/MeetingLogs/devweek0909/RegressionTests">https://wiki.ubuntu.com/MeetingLogs/devweek0909/RegressionTests</a></div> +<div><br></div><div>I think that using automated regession tests would make the job of QA a lot easier. Failures within packages would surface much faster and a lot of manual checking could be avoided. Don't get me wrong. Every package that would pass the regression tests should still be checked by a human. ;)</div> +<div><br></div><div>The following scenario could be used for this. After the package hast been generated, the RPM (or job) is passed to the regession test server. This server spawns a new virtual machine with the Mageia version the package should be checked on. When the machine is booted, the package is installed with all the needed dependencies and the tests are executed. If everyting went smooth, the package might be checked again by QA manually. If one or more tests failed, there is something wrong with package, although the package generation worked, and the maintainer/developer might want to take a look at it again.</div> +<div><br></div><div>To setup this up a combination of hudson (<a href="http://hudson-ci.org">hudson-ci.org</a>) and vagrant (<a href="http://vagrantup.com">vagrantup.com</a>) could be used. vagrant allows to use VirtualBox to boot serveral VM instances from base images that are thrown away after everything is done. This way multiple versions of Mageia could be tested on one well equipped server. One drawback with VirtualBox would be the missing ARM support.</div> +<div><br></div><div>Let's use something like a JSON lib for Python as an example. The package generation was successful. But Python is a highly dynamic language, so some submodule is missing due to a wrong install path, although "import json-xy" of the main module works flawlessly. Without further testing this will only surface when a poor developer uses the submodule or when a second package that depends on that submodule is tested by QA and shows errors or misbehaviours.</div> +<div>Second example, same lib. The JSON lib usually ships with a handy executable to lint check JSON files, but upstream decided to change that. Due to an error in the upstream repo, the executable script file is still there but it's empty or there is gibberish in it. There is no more lint checking possible with this executable. Automatic testing would show this very fast and without someone sitting there, pasting some JSON into a file to feed the executable with it.</div> +<div><br></div><div>Testing UI would be an other story, but I guess you get the idea. ;-)</div><div><br></div><div>That do you think about that? I think it would enhance the quality on Mageia in the long run and take some work from QA to find the really tricky bugs.</div> +<div><br></div><div>Regards,</div><div><br></div><div>Jochen</div></div> |