[arch-releng] Iso tests

Dan McGee dpmcgee at gmail.com
Wed Apr 20 21:32:29 EDT 2011


On Tue, Apr 19, 2011 at 2:51 AM, Dieter Plaetinck <dieter at plaetinck.be> wrote:
> On Tue, 19 Apr 2011 00:50:44 +0200
> Tom Willemsen <tom.willemsen at archlinux.us> wrote:
>
>> Everything on this list should now be done and checked in to
>> gitorious. The database has to be re-generated of course.
>
> nice to hear, I'll try it out as soon as I have time.
> unfortunately, my free time has decreased a bit as of late.
> So I encourage anyone who is interested in releng stuff and/or knows
> his way around in python/django to have a good look at Toms app and try
> it out.

Sorry I haven't had time to look at this yet. I will do so soon, hopefully.

Tom, two things- I'd like all new parts to use South migrations, so if
you could go ahead and generate the initial migration for this new
app, that would be awesome. Take a look at the docs if you aren't sure
what I'm talking about.

Second thing is- wondering if you could rebase your work on the latest
code. You branched quite a while ago and I'd prefer one line of clean
code that applies nicely, as it is a lot easier to follow. Something
like "git rebase master <mybranch>" should do the trick. It would also
be great if you could use "git rebase -i" or any other tricks to
squash fixup commits into the proper commit where that work originally
belonged.

My quick review since just pulled it down anyway:
* rtf ? I like this even less than isotests as far as WTF naming; I
had NO idea what that meant until I saw your commit. Why not just
"releng"?
* vim modeline on all files, like all existing files please.
* import statements: I try to do the following, with a blank line
between each, in this order: python, django, our app
* http://releng.archlinux.org/isos/ needs to be in the config file-
default in settings.py is fine, but it can't be hardcoded.
* "class(foo): pass" doesn't fly with me, I don't care how compact it
is. Just use the normal three lines so changing it later isn't a P in
the A.

>> I did notice that, when trying out conkeror again, the results page
>> may not show results immediately, but I don't get that in luakit, so
>> I don't know if it's conkeror that's loading its own cached pages
>> (only shows me after a refresh) or if it's luakit not loading
>> anything cached.
>
> weird. or maybe some kind of race condition, you do return the next
> page only when you're sure all the queries are committed, right?
It's not something like this, Django doesn't let you shoot yourself in
the foot like that unless you really try hard. It is probably just due
to some of the pages being cached in your browser, but without looking
closer I'm not sure.

-Dan


More information about the arch-releng mailing list