Merge lp:~rockstar/laika/more-cleanup into lp:laika
Status: | Merged |
---|---|
Approved by: | Alex Chiang |
Approved revision: | 21 |
Merged at revision: | 5 |
Proposed branch: | lp:~rockstar/laika/more-cleanup |
Merge into: | lp:laika |
Prerequisite: | lp:~rockstar/laika/foolin |
Diff against target: |
153 lines (+33/-56) 1 file modified
laika.py (+33/-56) |
To merge this branch: | bzr merge lp:~rockstar/laika/more-cleanup |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Alex Chiang | Approve | ||
Review via email: mp+30178@code.launchpad.net |
Description of the change
Here's what I did in this branch:
- Moved the global my_bugs var to be a member attr.
- Converted getopt usage to OptionParser, because it's a nicer API, and does the stuff from usage() automatically (try laika.py --help now). This meant I could remove a lot of code, and it'll be much easier to add more args.
- I noticed a bug where user wasn't anything but lp.me, so now we actually specify what user you want.
- There was a now var that was driving me nuts, because it really shouldn't be changed. In python, we don't really have true constants, but we denote variables that shouldn't be changed with all caps. Lame, yes, but I made it obvious.
- Main no longer cared about sys.args, so I killed that.
- cachedir didn't respect $HOME, so if was set to something other that /home/rockstar/, it was broken. I find that with os.path.expanduser, which knows how to expand ~ to $HOME.
The branch itself is bigger than I thought. Sorry about that.
No worries about large changes. I can handle those just fine, as long as the individual commits are sane.
The end result is good, but I'd like to see a little more discipline in the individual commits.
Two examples:
Commit 18 should have been folded into 16 in your development branch, so that I only see the a final, good commit. There's no need to clutter up the development history with bogus commits and then fixup commits. The Linux kernel will never knowingly merge a bad commit and then a fixup commit. [of course, bugs happen, but the goal is certainly clean commit history.] The reason is that bisection is an important tool, and we want to minimize the pain of landing on a bad commit during a bisect run. Of course, we don't have the same problem with laika, but I think it's still worth it to keep this discipline.
The last few lines of commit 14 logically seem like they belong with commit 13. When I was reading 13, I thought to myself, "hm, he added another call to Launchpad. login_with( ), but didn't remove the old one... why not?" I then inspected the final diff and saw that we indeed only ended up with a single call to Launchpad. login_with( ), but had to re-review the other commits until I found that 14 removed the double call.
Ok, in my opinion, these are nitpicky comments, but they address a real, fundamental philosophy about development.
Thanks for the patches, the refactoring is really nice.