To make things easier for your code reviewer, each patch should be small, and hold one well defined change. I break this rule all the time, and it comes back to bite me. What happens is that I get heads down coding, and I have a solution that involves changes to wide number of files and subsystems, new abstractions, etc. Here is how I am currently dealing with breaking down a big patch.
The SQL migration mechanism in Keystone is interesting enough to warrant some attention. If you need to modify the SQL database in any of the Open Stack projects, you are going to use a similar approach. Here is a step by step I have recorded of a SQL upgrade script I am writing for a feature in Keystone.
Continue reading
Gerrit is great, but one thing it does not do well is tell you the differences in an update to a review request. Here’s how I found I could focus review requests to just the deltas between submissions.
Continue reading
Embracing change is hard. Accepting criticism on code you worked so hard to prepare for review can be hard on the ego. But when you have additional work that is underway that depends on submissions undergoing review, it can also be a challenge to your organizational skills. I’ve recently learned a trick about git that makes this easier in the context of Open Stack development.
With Openstack, I find I often have a patch up for review that I want to use as the basis for future work. When a review comes in, I have to make the changes for the review and update the commit. There are a couple ways to go about doing it, but here is one that has worked for me. Continue reading
I’ve been working with the PKI/Dogtag code for a while. Over the past couple years, I’ve been more and more comfortable with Git. PKI uses SVN as a centralized Repository. Since Git SVN integration is fairly mature, I’ve been using that to manage my coding. On Monday, I gave a presentation to my team on Git SVN. I’ve taken the outline from the slides and included it here.
Continue reading
I posted before about how I get a patch ready for code review. Since I now also work on the Dogtag PKI project, I’ve extend the script to included configuration information from the projects .git/config.
Continue reading
FreeIPA requires that all code receive an ACK in a peer code review prior to submission to the main repository. While some patches can be reviewed inline in the email, more often the patch makes no sense without context.
Here’s a little ditty I wrote to get patches in the format we use for the FreeIPA mailing list:
As of today we are in early stages of development on a new UI approach for FreeIPA. Since the “bits are very fresh” we want to keep from breaking the existing code base. The policy for the upstream Repo for FreeIPA is that code must pass a fairly strenuous review process before getting checked in, and our code isn’t that way yet. However, there are two of us doing UI development, and we need to share our code back and forth prior to checking it in to the main repo.
This is a situation where git shines, and really can redefine your approach to development. I realize I am a late comer to git. I’m a bit of a Luddite, and slow to pick up on technologies in general, so this should come as no surprise. Here’s our approach.