[arch-releng] Iso tests

[Dan McGee]

On Thu, Mar 10, 2011 at 1:24 PM, Dieter Plaetinck <dieter at plaetinck.be> wrote:
> On Thu, 10 Mar 2011 19:17:37 +0100
> Tom Willemsen <tom.willemsen at archlinux.us> wrote:
>
>
>> > * 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.
>> That would be pretty cool, I only know it _should_ be possible if we
>> just grab credentials from the bbs/wiki/aur database, but I think that
>> would be beyond the scope of just the app I'm writing. Of course I could
>> look at how (re)captcha works.
>
> I think this app needs authentication (for webbased form input), there are 2 reasons in my previous mail.  Why do you think this app doesn't need authentication?
> captcha isn't needed if we have authentication.

Why does this need authentication at all? I'm totally confused on this one.

1. No way this will ever integrate with BBS/Wiki login unless you get
single sign-on working for everything anyway, so just forget that
idea. That has been a dream feature request for years
(https://bugs.archlinux.org/task/10703). If you want integration, then
this app should be a a) forum thread or b) wiki page.
2. Credibility- we ask for a name and email address here, so that is
something. You'll be able to see bogus results if they come through.
I'm not sure how this form is any more likely to result in spam than
posts to the ML, and if it does, don't accept forms without comments,
etc. There are plenty of ways to avoid garbage.

>> > * 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.
>> If it's just for testing you can easily git clone it and follow the
>> instructions provided in archweb's README, django has a very nice
>> testing webserver.
> I'll try.
>>
>> If you want it in a separate project so you can host it, that's also
>> fairly easy to do, I think, just let me know.
>>
>> > * 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.
>> I don't know, for as far as I've understood django just doesn't do
>> static pages, you place them where no django url points to on the web
>> sever and whichever webserver you're running should serve that static
>> page (I'm sure Dan or someone else can explain much clearer, sorry).
>
> AFAIK templates/public/download.html is a static page, maybe looking at that can help you.

Hardly static, and I hate the damn thing as people ride my ass if I am
an hour late updating and deploying it. I have to edit it every time
we do a release which is ridiculous, so please please please don't
follow this. If anything, and I have done this on other Django
projects, we should add a "StaticContent" type model that allows
arbitrary admin controlled bits and pieces of content to be displayed
on our various pages.

>> But wouldn't that be a good idea for a wiki page that is linked to,
>> maybe?
> nah, the help page is tied to this application, so the code for
> it should go along with the source code of the app.  it should also be served
> with the same style, etc.

-1. This is a website, not a version controlled living document as the
help page could be (what code is here?). The wiki accommodates this
stuff perfectly. We've moved a lot of our home page links away from
static-type pages and over to the wiki for this reason; this one seems
no different to me.

Wow, I sound negative- sorry 'bout that, but I'm just trying to share
from the (bad) decisions made in the past.

-Dan