On Thu, 10 Mar 2011 10:04:24 -0600 Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Mar 10, 2011 at 3:43 AM, Tom Willemsen <tom.willemsen@archlinux.us> wrote:
Hello people of arch-releng,
A while ago Dieter asked if someone could write him a (relatively) simple web-app to get a better view of the state of the auto-generated isos. I tried that and have now come up with something to look at. He asked me to send a mail to this list so we could have a look at it in public, so here it is. It's hosted at: http://www.gitorious.org/ryuslash/archweb
I just branched the archlinux website, since Dieter said he might want it to be a part of it, and it's written in django anyway so it's fairly easy to rip it out and place it in a new project. My code is in the testsresults branch in the afore mentioned repo, to set it up just follow the instructions in the archweb README, I added some fixtures so that things like bootloaders don't have to be entered manually by everyone. The /isotests/ page shows the results that have been entered so far, I tried sticking closely to what Dieter requested. The /isotests/add/ page allows you to add a new result.
I would have liked to put the app in a repo of its own, but I didn't find how I can make the templates load from the app/templates directory, so I moved on to this idea.
I don't have a lot of experience with django, so I could be doing some things in a very silly way, I haven't cleaned up the code I've written at all (I should probably do that soon, I'll get on it tonight), but I hope that this is at least an ok starting point.
I hope I exlpained everything enough, if there's anything I still need to do, fix or change just let me know and I'll get on it as soon as I can.
Nice! I'd be glad to have this hosted on the main site (I'm the maintainer). Overall things look sound; sure there are some style/convention/etc. differences but nothing hard to fix up.
* View page: right now it is making 98 queries (one for each of those max values). Not that this page is probably going to see loads of traffic but we can surely improve upon that. * Add page: Using radio buttons for widgets here would probably be smarter than the dropdowns, otherwise field entry is excruciatingly painful. See the forms documentation for how to change the default widget. * models, Test.ms: totally un-descriptive field name, and you didn't give it a nice field name. Can't this just be "modules"? * models, Test: if you name things boot_type instead of boottype, you'll get nicer default labels on your view and entry screens. Same with the models themselves- Boottype -> BootType. * models, Iso: Likely need more than a date field here. We've double released, etc. It might just be worth having a CharField as no users are going to be entering these anyway, and also having a boolean "active" field or something to determine what actually shows up on the entry and view pages. * models, get_success_test/get_failed_test: these can be abstracted into a common proxy model (http://docs.djangoproject.com/en/1.2/topics/db/models/#proxy-models) superclass, from which all these various ISO options inherit from. * tests.py: yes, we should be writing tests, but at the least, get rid of the default garbage in this file. * admin.py: convention is not to use * imports; I know it works here and makes things cleaner but I've eradicated the codebase of them otherwise. * models.py: "# Create your models here." -> not needed * urls.py: You aren't using info_dict anymore; you have a blank second pattern definition?, and I'd prefer you follow indentation patterns of something like packages/urls.py. * views.py, add: A lot of extra comments. "Create your views here.", all the "form been submitted" trailing stuff. For the return, I've switched to using mostly direct_to_template to avoid some of the boilerplate- see the end of flag() in packages/views.py around line 373 for an example. * views.py:, view: I see some things are _choices, some are _list- why the disparity? * isotest/templates: why is this in a different directory from the standard layout? * Finally, I see 4 + 1 templates, but only two views- are these other ones old, unnecessary, not wired up yet?
Great work! I know I just said a lot but these are mostly minor things, nothing to feel bad about.
-Dan
Thanks Tom, I know nothing about django, so thank you Dan for providing your input there. my notes: * add something like: autocmd BufWritePre *.py :%s/\s\+$//e to your .vimrc, it makes sure you won't commit trailing whitespace. (oh right you use emacs right? well, configure it ;-) * there will need to be some kind of "are you human test" on the input form (a simple question/response check might do fine, like "which Linux distro is this about? (just the 4-letter word)") * I would prefer even some sort of authentication. if there was a way to allow people to authenticate with their bbs or archwiki login, or even get cookies from the wiki (does archlinux.org get the cookies from wiki.archlinux.org?) this will be needed to have some credibility for entries, as well as a way to get back to the user if I have any questions about their report. also if we have this, we don't need the 'are you human' test. * I will need to install this either locally (any tips on that?) or maybe we host it on archlinux.org directly (if that seems safe enough, Dan? note that we'll need to update it regularly to test updates, but I could review code/queries - but I have zero django knowledge), when I do that, I can give feedback on the actual features and workflow. * Can you provide a sample static page called "help" or something? When I have a setup that I can test on, I can start writing the contents for that help page. It will be needed anyway for users who want to use the app, and at the same time it can serve as implementation guideline for you. Dieter