[arch-general] who wants to write me a relatively simple webapp?
Hi, for Arch releng, we have recently started automatically building test builds (http://releng.archlinux.org/isos/). These images are built from the archiso and aif git repositories, and the current state of the repos. The idea is that people can test these images, and once in a while, I will promote a set of testbuilds and make them the officially supported media. Because everything evolves all the time, a lot of different things can cause regressions or new bugs, but at the same time it would be too much work to try to test all possible scenarios for each specific testbuild version. So I would like a web application that gives me "a pretty good idea" of the quality of current/recent images. I request someone other then me to make this app for me, I do not have the time. (I do have time for feedback or making adjustments to the codebase you provide) I'm not sure which is best, php or python, or whatever. I think both will be fine (Dan? Pierre?) Basically it would have 2 modes: 1) the "input" mode (after logging in with your wiki or forum account, not sure what's best here. Dan?): the user would select a version (maintain a cached list of the directories at http://releng.archlinux.org/isos/ the format will always be YYYY.MM.DD[suffix]) and select a list of options which are verified to be working fine. that is: (between braces are additional instructions for the user) = image arch = * dual, option i686 * dual, option x86_64 * i686 * x86_64 = image type = * core * net = image boot = * optical * usb * pxe = hardware type = * virtualbox * qemu * physical intel i686 * physical intel x86_64 * physical amd i686 * physical amd x86_64 = install type = * automatic install generic example * automatic install fancy example * automatic install custom config (specify in comments) * interactive install = source selection = * net install manual networking config (check that it works + rc.conf, resolv.conf, mirrorlist) * net install dhcp (check that it works + rc.conf) * core = clock = * left as is * reconfigured manually * reconfigured ntp = partitioning/filesystems = * autoprepare (check the installed system, incl fstab) * manual * from config file = fancy stuff (checklist, not selection) = * lvm2 * dm_crypt * softraid * nilfs2 * btrfs (check also fstab, menu.lst, initcpio.conf and crypttab if appropriate) = rollback tested = * yes * no = if rollback done, another partitioning/filesystems list and another "fancy stuff" list (same options as before) for after the rollback = = bootloader = * grub * syslinux * other/manual = result = * everything works fine * something failed (elaborate in comments) = comments = <textarea> Then, a second interface would need to represent the "current state of things.. (sort of)" that is, for every important thing (like, all image arches, image types, image boots, install types, source selections, clock, partitioning/filesystems, fancy stuff, rollback tested, grub/syslinux bootloader) it needs to show the last recent tests (or the last images for which it worked), along with which user tested it. (note: not all combinations of all variables, just any test with the given variable). if there was any failed test for a specific feature for an as recent (or more recent) image then the last successful one, there should be a warning about that. I'm not sure yet how exactly this page would look like, but basically I need to know all important features are tested with recent images, and that they all performed well. other factors (like hardware type, bootloader other/manual bootloader option) are not very important, they are more for reference. Thanks, Dieter
How much are you willing to pay for this piece of bespoke software? /M On 07/02/11 22:52, Dieter Plaetinck wrote:
Hi, for Arch releng, we have recently started automatically building test builds (http://releng.archlinux.org/isos/). These images are built from the archiso and aif git repositories, and the current state of the repos.
The idea is that people can test these images, and once in a while, I will promote a set of testbuilds and make them the officially supported media. Because everything evolves all the time, a lot of different things can cause regressions or new bugs, but at the same time it would be too much work to try to test all possible scenarios for each specific testbuild version.
So I would like a web application that gives me "a pretty good idea" of the quality of current/recent images. I request someone other then me to make this app for me, I do not have the time. (I do have time for feedback or making adjustments to the codebase you provide) I'm not sure which is best, php or python, or whatever. I think both will be fine (Dan? Pierre?)
Basically it would have 2 modes:
1) the "input" mode (after logging in with your wiki or forum account, not sure what's best here. Dan?): the user would select a version (maintain a cached list of the directories at http://releng.archlinux.org/isos/ the format will always be YYYY.MM.DD[suffix]) and select a list of options which are verified to be working fine. that is: (between braces are additional instructions for the user)
= image arch = * dual, option i686 * dual, option x86_64 * i686 * x86_64
= image type = * core * net
= image boot = * optical * usb * pxe
= hardware type = * virtualbox * qemu * physical intel i686 * physical intel x86_64 * physical amd i686 * physical amd x86_64
= install type = * automatic install generic example * automatic install fancy example * automatic install custom config (specify in comments) * interactive install
= source selection = * net install manual networking config (check that it works + rc.conf, resolv.conf, mirrorlist) * net install dhcp (check that it works + rc.conf) * core
= clock = * left as is * reconfigured manually * reconfigured ntp
= partitioning/filesystems = * autoprepare (check the installed system, incl fstab) * manual * from config file
= fancy stuff (checklist, not selection) = * lvm2 * dm_crypt * softraid * nilfs2 * btrfs (check also fstab, menu.lst, initcpio.conf and crypttab if appropriate)
= rollback tested = * yes * no
= if rollback done, another partitioning/filesystems list and another "fancy stuff" list (same options as before) for after the rollback =
= bootloader = * grub * syslinux * other/manual
= result = * everything works fine * something failed (elaborate in comments)
= comments = <textarea>
Then, a second interface would need to represent the "current state of things.. (sort of)" that is, for every important thing (like, all image arches, image types, image boots, install types, source selections, clock, partitioning/filesystems, fancy stuff, rollback tested, grub/syslinux bootloader) it needs to show the last recent tests (or the last images for which it worked), along with which user tested it. (note: not all combinations of all variables, just any test with the given variable). if there was any failed test for a specific feature for an as recent (or more recent) image then the last successful one, there should be a warning about that. I'm not sure yet how exactly this page would look like, but basically I need to know all important features are tested with recent images, and that they all performed well.
other factors (like hardware type, bootloader other/manual bootloader option) are not very important, they are more for reference.
Thanks, Dieter
-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On 02/07/2011 06:41 PM, Magnus Therning wrote:
On 07/02/11 22:52, Dieter Plaetinck wrote:
Hi, for Arch releng, we have recently started automatically building test builds (http://releng.archlinux.org/isos/). These images are built from the archiso and aif git repositories, and the current state of the repos.
The idea is that people can test these images, and once in a while, I will promote a set of testbuilds and make them the officially supported media. Because everything evolves all the time, a lot of different things can cause regressions or new bugs, but at the same time it would be too much work to try to test all possible scenarios for each specific testbuild version.
So I would like a web application that gives me "a pretty good idea" of the quality of current/recent images. I request someone other then me to make this app for me, I do not have the time. (I do have time for feedback or making adjustments to the codebase you provide) I'm not sure which is best, php or python, or whatever. I think both will be fine (Dan? Pierre?)
Basically it would have 2 modes:
1) the "input" mode (after logging in with your wiki or forum account, not sure what's best here. Dan?): the user would select a version (maintain a cached list of the directories at http://releng.archlinux.org/isos/ the format will always be YYYY.MM.DD[suffix]) and select a list of options which are verified to be working fine. that is: (between braces are additional instructions for the user)
= image arch = * dual, option i686 * dual, option x86_64 * i686 * x86_64
= image type = * core * net
= image boot = * optical * usb * pxe
= hardware type = * virtualbox * qemu * physical intel i686 * physical intel x86_64 * physical amd i686 * physical amd x86_64
= install type = * automatic install generic example * automatic install fancy example * automatic install custom config (specify in comments) * interactive install
= source selection = * net install manual networking config (check that it works + rc.conf, resolv.conf, mirrorlist) * net install dhcp (check that it works + rc.conf) * core
= clock = * left as is * reconfigured manually * reconfigured ntp
= partitioning/filesystems = * autoprepare (check the installed system, incl fstab) * manual * from config file
= fancy stuff (checklist, not selection) = * lvm2 * dm_crypt * softraid * nilfs2 * btrfs (check also fstab, menu.lst, initcpio.conf and crypttab if appropriate)
= rollback tested = * yes * no
= if rollback done, another partitioning/filesystems list and another "fancy stuff" list (same options as before) for after the rollback =
= bootloader = * grub * syslinux * other/manual
= result = * everything works fine * something failed (elaborate in comments)
= comments = <textarea>
Then, a second interface would need to represent the "current state of things.. (sort of)" that is, for every important thing (like, all image arches, image types, image boots, install types, source selections, clock, partitioning/filesystems, fancy stuff, rollback tested, grub/syslinux bootloader) it needs to show the last recent tests (or the last images for which it worked), along with which user tested it. (note: not all combinations of all variables, just any test with the given variable). if there was any failed test for a specific feature for an as recent (or more recent) image then the last successful one, there should be a warning about that. I'm not sure yet how exactly this page would look like, but basically I need to know all important features are tested with recent images, and that they all performed well.
other factors (like hardware type, bootloader other/manual bootloader option) are not very important, they are more for reference.
Thanks, Dieter How much are you willing to pay for this piece of bespoke software?
/M
First: I really, really, hope this was a poor attempt at humour! Second: Please don't top post. http://idallen.com/topposting.html
On Mon, Feb 7, 2011 at 5:41 PM, Magnus Therning
How much are you willing to pay for this piece of bespoke software?
my guess would be the noble sum of $0,000.00; he might even throw in everything under the couch cushions if the app turns out pretty good :-) C Anthony
On Mon, Feb 7, 2011 at 5:52 PM, Dieter Plaetinck
So I would like a web application that gives me "a pretty good idea" of the quality of current/recent images. I request someone other then me to make this app for me, I do not have the time. (I do have time for feedback or making adjustments to the codebase you provide) I'm not sure which is best, php or python, or whatever. I think both will be fine (Dan? Pierre?)
Hey I might be able to do it. But it's not going to look pretty because I'm not a designer. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On Mon, Feb 07, 2011 at 07:40:24PM -0500, Kaiting Chen wrote:
Hey I might be able to do it. But it's not going to look pretty because I'm not a designer. --Kaiting. How is this going? Because I would also like to help/do it.
Same thing applies though, not a designer :) Tom
Am 10.02.2011 10:39, schrieb Tom Willemsen:
On Mon, Feb 07, 2011 at 07:40:24PM -0500, Kaiting Chen wrote:
Hey I might be able to do it. But it's not going to look pretty because I'm not a designer. --Kaiting. How is this going? Because I would also like to help/do it.
Same thing applies though, not a designer :)
I say, simply apply the Arch design to it. It is, after all, supposed to be an official Arch site.
On Thu, 10 Feb 2011 10:47:51 +0100
Thomas Bächler
Am 10.02.2011 10:39, schrieb Tom Willemsen:
On Mon, Feb 07, 2011 at 07:40:24PM -0500, Kaiting Chen wrote:
Hey I might be able to do it. But it's not going to look pretty because I'm not a designer. --Kaiting. How is this going? Because I would also like to help/do it.
Same thing applies though, not a designer :)
I say, simply apply the Arch design to it. It is, after all, supposed to be an official Arch site.
how is it going -> it's not going yet. design -> personally I don't care. A white page with black text would be fine for me. Functionality is what matters. But also what Thomas said, it should be easy to find the Arch theme somewhere (we have git repo's for archweb, our forums, wiki, etc) Dieter
On Thu, Feb 10, 2011 at 10:47:51AM +0100, Thomas Bächler wrote:
Am 10.02.2011 10:39, schrieb Tom Willemsen:
On Mon, Feb 07, 2011 at 07:40:24PM -0500, Kaiting Chen wrote:
Hey I might be able to do it. But it's not going to look pretty because I'm not a designer. --Kaiting. How is this going? Because I would also like to help/do it.
Same thing applies though, not a designer :)
I say, simply apply the Arch design to it. It is, after all, supposed to be an official Arch site.
yeah I was thinking he/we/I could try that.
Note that I've been talking with Tom on Fosdem, and we already privately mailed about this. In a mail he asked "why not let AIF create a textfile automatically, then just submit that textfile to the webapp?" I think that's a good idea: - less manual work for the user. - no webform needed (but we need a tool that submits the info, and the webapp still needs to parse incoming post data) - authentication is probably also not needed (we just kindly ask users to fill in their forum nickname, but they could enter $whatever, so we need to do some sanitizing) Also note: - internet will be needed from the installed target system - the system can only be verified to be installed correctly after booting it. (I don't think this is an issue) - further manual input is needed (fill in nickname, explain issues, add comments, ..) - AIF already logs quite some stuff. Maybe we should write a tool that parses the logfile locally, builds the used parameters, then asks user to fill in more stuff, and finally submits the stuff. Once the webapp schema needed to fulfill the requirements is figured out, we can figure out the needed POST parameters and then it should be fairly easy to write the tool that parses the logfile. the aif log is only available on the live system, not on the target system, maybe we should just copy the log to the target's /var/log. since "the tool" would then be installed on the target system with pacman -S, it can be written in any language (python, bash, ..). Dieter
Hey Tom, what's the status? If you have any questions, just let me know how I can help. If you're not interested anymore, then let me know also, then I can search for someone else :) Dieter
Hey Tom, what's the status? I'm very sorry, I haven't been able to get to it yet, I've only been able to look at how django works, I'd forgotten most of it, but it seems
If you have any questions, just let me know how I can help. Well yes I did have a question, what were your thoughts on how to view
Hey Dieter, On Sat, Feb 19, 2011 at 05:56:47PM +0100, Dieter Plaetinck wrote: like the best idea to me right now. the data? Just a table filled with what everyone filled in or something else?
If you're not interested anymore, then let me know also, then I can search for someone else :) No I'm still very eager to do this, I'm sorry I haven't had time yet, but I will try to work on it some today and tomorrow and see how far I get.
Dieter
Greetings, Tom
On Sat, 19 Feb 2011 20:44:22 +0100
Tom Willemsen
Hey Dieter,
Hey Tom, what's the status? I'm very sorry, I haven't been able to get to it yet, I've only been able to look at how django works, I'd forgotten most of it, but it seems
On Sat, Feb 19, 2011 at 05:56:47PM +0100, Dieter Plaetinck wrote: like the best idea to me right now.
If you have any questions, just let me know how I can help. Well yes I did have a question, what were your thoughts on how to view the data? Just a table filled with what everyone filled in or something else?
well I think it would be best to have a table that shows for each value of each criterion, the last succesful state (if known) so, for example: criterion ---- last known state Arch: - i686 OK on 2011.02.10 (tested by $user) - x86_64 OK on 2011.02.05 (tested by $user) - dual/i686 not tested yet - dual/x86_64 FAILED on 2011.01.25 (tested by $user) Image type: - Core OK on 2011.02.10 (tested by $user) - Netinstall OK on 2011.01.18 (tested by $user) and so on (see my first mail for all criteria) So, since every test report is a combination of reports for specific things (like "i tested an install with the i686 core image, with manual partitioning, ntp clock setting, etc etc and it worked fine"), but it will cause updates for various properties in the table above. Dieter
well I think it would be best to have a table that shows for each value of each criterion, the last succesful state (if known)
so, for example:
criterion ---- last known state Arch: - i686 OK on 2011.02.10 (tested by $user) - x86_64 OK on 2011.02.05 (tested by $user) - dual/i686 not tested yet - dual/x86_64 FAILED on 2011.01.25 (tested by $user)
Image type: - Core OK on 2011.02.10 (tested by $user) - Netinstall OK on 2011.01.18 (tested by $user)
and so on (see my first mail for all criteria)
So, since every test report is a combination of reports for specific things (like "i tested an install with the i686 core image, with manual partitioning, ntp clock setting, etc etc and it worked fine"), but it will cause updates for various properties in the table above.
Dieter
Won't that get troublesome though? I mean, someone tests it with i686, core, automatic partitioning and it works, but then someone tests it with i686, net, automatic partioning and it doesn't. At this point i686 will have worked, core will have worked and automatic partitioning will have worked, but only net won't have. But then someone might test it with x86_64 and that does work (ok so maybe using the core/net difference might be a bad idea? sorry) then net will have worked too, but not on i686 which might not be apparent from this data. Or am I just being picky? Tom
On Sat, 19 Feb 2011 23:58:23 +0100
Tom Willemsen
well I think it would be best to have a table that shows for each value of each criterion, the last succesful state (if known)
so, for example:
criterion ---- last known state Arch: - i686 OK on 2011.02.10 (tested by $user) - x86_64 OK on 2011.02.05 (tested by $user) - dual/i686 not tested yet - dual/x86_64 FAILED on 2011.01.25 (tested by $user)
Image type: - Core OK on 2011.02.10 (tested by $user) - Netinstall OK on 2011.01.18 (tested by $user)
and so on (see my first mail for all criteria)
So, since every test report is a combination of reports for specific things (like "i tested an install with the i686 core image, with manual partitioning, ntp clock setting, etc etc and it worked fine"), but it will cause updates for various properties in the table above.
Dieter
Won't that get troublesome though? I mean, someone tests it with i686, core, automatic partitioning and it works, but then someone tests it with i686, net, automatic partioning and it doesn't. At this point i686 will have worked, core will have worked and automatic partitioning will have worked, but only net won't have. But then someone might test it with x86_64 and that does work (ok so maybe using the core/net difference might be a bad idea? sorry) then net will have worked too, but not on i686 which might not be apparent from this data. Or am I just being picky?
Tom
Well, the parameters are usually independent from each other. for example the netinstall code is the same, whether you use the i686 image or the x86_64 one, and whether you use an i686 repo or an x86_64 one. there might be some correlations between parameters but if we can already make the webapp work and do the report as described (without showing "other parameters used in the test case that failed"), that would already be a great step. And the idea is to reach 0 failures anyway, so as soon as something fails, we need to debug why and fix it, so that all entries become 'OK' again for later images. The user can also supply comments (and hopefully he will make a ticket on the bugtracker with detailed info). If you want, you can provide further interfaces to show complete reports, link to those from the main table and so on, but let's first get the basics working. Dieter
participants (7)
-
C Anthony Risinger
-
Dieter Plaetinck
-
Kaiting Chen
-
Magnus Therning
-
Matthew Gyurgyik
-
Thomas Bächler
-
Tom Willemsen