Saturday, January 21, 2012

Cleaning Up Branch Checkouts

Since Twisted development typically involves at least one branch per ticket, a Twisted developer can end up with a lot of branches checked out.  For example, this morning I had 177 Twisted branches checked out on my laptop.  Many of these were branches that I contributed code to, and perhaps even merged into trunk myself when they were complete.  I could probably have deleted them at that point, but I usually can't be bothered.  Besides, I put everything I have into the branch itself, by the time I'm merging it I'm done.  Other branches are ones I've done code reviews on for other developers.  I don't keep track of when these get merged into trunk as closely, since typically someone else is going to do those merges.

The incremental cost of another Twisted branch is pretty minimal.  A few more megs used on my hard drive is barely noticable.  The aggregate cost can get pretty high though (Seven GB for the 177 branches I had this morning).  At some point this can cause problems.

Not all of these branches have been merged to into trunk, either, or I could just wipe them all out with ease.  And while I try never to leave uncommitted changes in a branch checkout, nobody's perfect...  What I really want to do is just get rid of the branches that just aren't relevant anymore.

So I use cleanup-local.py to deal with the mess.  It looks at my branch checkouts, talks to the Twisted issue tracker to learn the state of the associated ticket (due to the naming convention for Twisted branches, it is easy to determine which ticket is associated with a branch, given just the branch name).  Then it deletes all the checkouts associated with closed tickets (due to the Twisted workflow, if a ticket is closed, it is a very safe bet that you won't need its branch anymore).

The net result is that in (far) less time than it took to write this post, my laptop went from having 177 Twisted branches to having just 34.  To save even more time, I could probably set this up as a weekly cron job or something similar.  It's easy enough to run now, though, that I just do so manually once every couple of months to keep things tidy.

Here's a brief snippet from today's run:

Found password-comparison-4536-2 for ticket(s): 4536
Status of 4536 is assigned
Found pb-chat-example-4459 for ticket(s): 4459
Status of 4459 is closed
Removing closed: pb-chat-example-4459
Found plugin-cache-2409 for ticket(s): 2409
Status of 2409 is closed
Removing closed: plugin-cache-2409
Found poll-default-2234-2 for ticket(s): 2234
Status of 2234 is closed
Removing closed: poll-default-2234-2

Tuesday, January 10, 2012

Learn About Twisted at PyCon 2012

At PyCon this year I'll be presenting a tutorial to introduce Python programmers to Twisted. This tutorial has two goals. First, to give attendees a firm grasp of Twisted's concurrency model, both in the abstract and the concrete. Second, to remove the mystery around the tools Twisted provides for developing robust, testable concurrent applications. If you attend, you'll come away with an understanding of how event loops work and how to write code that works best in Twisted's event loop.

I am a long time core Twisted developer with real world experience building maintainable, scalable systems with Twisted. I've also presented similar introductory Twisted tutorials several times in the past, letting me learn the common sticking points and teaching approaches to help overcome them.

Check out the tutorial's page on the PyCon 2012 website for details about what will be covered. Come learn how to leverage Twisted and Twisted-based libraries to their fullest extent!

Monday, October 31, 2011

Don't Use Buildbot EC2 Features

I just noticed that Buildbot spun up one EC2 instance 31 days ago and another one 14 days ago and left them both running.

Wednesday, October 12, 2011

Garlic Followup

Previously I shared some pictures of a garden bed Jericho and I have been working on. Over the long weekend we had some more time to spend on it. While we were away, we got some help preparing the rest of the garden, which would have otherwise taken weeks or months to do by hand:

You can see the oats we put in at the beginning of September in the garlic ged on the left side there. They didn't grow as much as I had hoped:

Perhaps due to some nutrient or mineral deficiency. To rectify that (and based on a soil test), we spread a number of amendments, starting with greensand to provide potassium:

We also spread rock phosphate (for phosphorus) and pelletized lime for calcium and to adjust the pH to be less acidic. And, importantly, compost - about 1 cubic yard over the entire bed (with which task my dad helped us out):

As you can see, we just left the oats in place. They are not cold hardy and will die soon enough without any help. With the bed thusly prepped, we began breaking up our "seed" garlic:

Garlic is most often grown by sowing cloves in the autumn for harvest the following summer. The winter encourages the clove to split and grow into a new bulb. We planted four varieties of garlic, but mostly Inchelium, a softneck variety.

These seed bulbs each had around a dozen cloves in them.

We planted the largest undamaged cloves. We also planted three varieties of hardneck garlic. Compared to the inchelium, these all look pretty similar to each other. Here's some Siberian Red:

The hardneck varieties have bulbs with fewer, larger cloves. After we broke up the cloves, we planted them! While one of us dropped cloves in pre-marked locations, the other followed behind and planted them.

The cloves are planted right-side-up about one inch deep. Finally we mulched them with straw to even out temperature variations and retain moisture.

Now the garlic sits tight until next year.

Wednesday, September 7, 2011

Garden Bed Prep

Over the long weekend, Jericho and I made a garden bed. We picked a plot a few minutes walk from the new orchard and started by mowing a 100' x 4' area.

That's Lucy, my mom's lab, down near the end. Next we cut sod with shovels.

I dug too, but Jericho doesn't take as many pictures as I do.

After that, we flipped sod. First one row of it:

And then the next row:

After all the sod was out, we dug a little more.

Then we put the sod at the bottom of the hole, upside-down, where it will hopefully die and contribute organic material to the soil.

And then we shoveled that dirt off the tarp, back into the hole on top of the sod, and raked it flat.

And again.

Until all the dirt was back in the bed.

This will be a garlic bed. We'll plant the garlic in October. Until then, we put in a quick cover crop of oats.

Then I rubbed some dirt on my shirt to make it look like I helped too.

A few hours after we finished seeding, a nice thunderstorm rolled in and watered everything for us.

If all goes well, in about a month we'll have some nice young oats to mow down before planting garlic in the bed.

Releasing Python Software is Tedious

I released pyOpenSSL 0.13 a few days ago. Apart from making sure it actually worked on various platforms, updating the version number, regenerating the documentation, and sending out the release announcement, I also had to upload release files to the Python Package Index.

Uploading release files to PyPI is the part of the release process I hate the most. pyOpenSSL 0.13 had 15 files to upload to PyPI. There is no usable automated interface for uploading files to PyPI. Before I can even begin to upload them, I have to download them from the build farm where they're generated. Then, uploading just one file to PyPI requires at least 8 mouse clicks. The clicks vary depending on which file is being uploaded. I have to select a file, select its type, specify which Python version it's for, and then submit a form.

15 files, 8 clicks per file. Well, you do the math. It's not a pleasant experience. PyPI would be a much better resource if it didn't force me to specify a ton of redundant, mostly useless information every time I do a release. It would be a much better resource if it had a programmatic interface so I don't have to spend 20 minutes clicking buttons in web browser. It would be a much better resource if it didn't try to hard to discourage me from releasing software.