> 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.
Very well, I'll start reading. > 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. I'll try, never used rebase before. > 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"? Just "releng"? Seems too generic, this app only deals with a small part of releng, the "releng-testbuild-feedback". Wouldn't that be preferable? > * 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 No problem. > * http://releng.archlinux.org/isos/ needs to be in the config file- > default in settings.py is fine, but it can't be hardcoded. Of course, how could I forget. > * "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 thought you were going to say that. I'll get to these points tonight or otherwise this weekend. Tom
