[arch-releng] Iso tests

[Dieter Plaetinck]

On Fri, 11 Mar 2011 09:11:38 +0100
Tom Willemsen <tom.willemsen at archlinux.us> wrote:

> On 10 Mar 22:59, Dieter Plaetinck wrote:
> > the pages should have links to each other so that you can navigate
> > to all pages.
> I didn't do this yet because I don't know how other apps within
> archweb manage their own menus. And I also didn't want to mess around
> with archweb's main menu yet since I'm not even sure if the name is
> ok yet :)

"isotests" is a good name imho. well, almost.  the app is not only
about iso's but also about images for usb/pxe. so maybe
"testbuild-feedback" but then that's not really clear it's about releng
stuff, and "releng-testbuild-feedback" is a bit verbose.
maybe "RTF" (acronym for the latter) ?, maybe you guys can come up with
something good.

On Fri, 11 Mar 2011 09:08:16 +0100
Tom Willemsen <tom.willemsen at archlinux.us> wrote:
> On 10 Mar 16:24, Dan McGee wrote:
> > Aha, then a Django management command works fine for this, we
> > already have several. You are still going to have some issues with
> > that dropdown being far too full of things if they are this
> > continuous, or do you plan on pruning old ISOs so we can just mark
> > those inactive in the list?
> 
> Aha interesting, I'll look at that, if that's ok.
> 
> I thought maybe any iso's that come before an official release iso
> might be best marked as inactive? Maybe then we also need to keep an
> 'official' field so that can be checked and isos before it might be
> automatically marked as inactive at that point?

The only thing we need is a way to limit the list of iso's on the "add"
page to current ones. (like, only display the most recent 20). 
If you also want a page where you just give a plain list of reports,
you should limit it to the 100 most recent or something.
Anything else (explicit marking as inactive, pruning old reports,...)
sounds like YAGNI to me.



On Fri, 11 Mar 2011 09:24:41 +0100
Tom Willemsen <tom.willemsen at archlinux.us> wrote:

> On 10 Mar 22:01, Dieter Plaetinck wrote:
> > okay, so no authentication reuse.
> > then i guess the next best thing is to ask a (nick)name, email
> > address and response to a simple "are you human" question. that
> > should work well enough, except it would allow people to purposely
> > add "everything is okay" reports with a bogus name/ email address,
> > which would cause me to mark iso's as "verified enough" and make an
> > official release of crappy isos. (or the inverse: they can mark as
> > everything as broken).  if users would be authenticated I think
> > there would be less chance for abuse.
> So how would we do that? a question like which arch is best? or
> should I start looking at captcha or something?

Any question which can be easily answered by a person who wants to add
a report, but not by a spam bot. captchas are generally considered
unpleasant by visitors, regular questions are more acceptable. (and
they are probably easier for you as well)

> 
> Another idea might be (although might cause other problems of course,
> and would require more effort on the user's part) that results have to
> be verified, like forum logins and such.
> As I think that everyone who takes the time to use a web interface to
> enter these questions might already be motivated enough to also
> respond to a simple single-click verification, perhaps. And I don't
> think many people would test a single iso all that many times, at
> most they might enter a new result if they changed their settings
> from last time. But it still might not be the nicest idea.

"must be verified, like forum logins" => this is called authentication.
But I'm not sure how exactly you want to authenticate them. "simple
single-click verification" ? How would that work?


> > However, if that is not something we want (it would for example
> > imply I need push access to the repo) or have time to setup right
> > now, I can live with the next best thing: maintaining the help page
> > on the wiki. (I don't like the idea of managing the page content
> > through the webinterface, I want version control, so let's keep
> > this webapp simple and let's not poorly reinvent a wiki)
> So what is it then you have against the wiki exactly? just the fact
> that it's managed through a web interface? Since I thought the wiki
> was version controlled anyway (looking at the history tab sure gives
> me an idea much like it) and I thought it would be the logical place
> for any arch-related documentation? I don't want to be a pain I just
> don't follow completely :)

Yes, a wiki is version controlled, you must have misunderstood me.
I prefer maintaining documentation in git and "agile"-style deployments
 (where I can easily update the code on the server in a reliable way)
If that's not possible (or too much work to setup), then a wiki is the
next best thing.
"next best", and not "best" because git >> mediawiki versioning,
cli/vim >> webinterface and I prefer the page to be integrated (both
visually, and by its url) with the app.
Maintaining this on the wiki is not my preference, but I can live with
it.

Dieter