Tag Archives: git

Git by a bus.

David Gay pointed me to an interesting project called Git by a Bus. Git by a Bus analyzes your git repository and attempts to quantify risk of having lots of code knowledge tied up in only a few people. Git by a Bus does its analysis by going through the repo history and making an estimate of what it calls unique knowledge.

This project blog page describes the analysis and metrics used. Perhaps this is a useful way to show how Fedora is doing as a project, across repositories like our web applications and infrastructure. It might show where we need to encourage further community development and participation so we avoid the “eaten by raptors” problem.

You might recall that “eaten by raptors” is Fedora shorthand for “hit by a bus” (violent idiom) or “going to work for another company” (not always applicable to Fedora, although certainly to Red Hat as a major contributor). We try to solve this problem by spreading project knowledge and documenting our processes. That way, if someone was eaten by velociraptors, the project can keep going without too much of a disturbance. This problem is common to any team or enterprise, not just open source. But I like to think our velociraptor spin is unique.

Here’s an example output I prepared for the MirrorManager project, which we use to provide content to Fedora mirrors worldwide. This is a potential example of high risk. One developer (the inimitable and awesome Matt Domsch) has unique knowledge of this project that is at risk if velociraptors manage to track and eat him. No doubt Matt would put up a good fight, but as you probably know they are clever girls.

Thankfully, there is a MirrorManager related Fedora Activity Day happening later this year. During that time the Fedora infrastructure, release engineering, and applications teams hope to accumulate and document more MM-related knowledge. At the same time they’ll be using this knowledge to architect, plan, and further develop the next revision of MirrorManager.

If you’re a principal in an FOSS project using git for your code, you might find Git by a Bus useful.

Finding old test packages in Koji.

After I answered a question on the devel list today about getting one’s hands on an old testing package for Fedora that had been obsoleted or removed, Josh Boyer one-upped me by providing some easy instructions. I figured I would tip my fedora to him by building a blog post on his work. Nice one, Josh!

When someone builds an official Fedora package, whether it ultimately gets moved to stable or not, there’s a record for it in Koji, the Fedora package build system. You can use the search bar on the Koji website to find the package or build you’re inerested in. In the resulting page, you’ll find the build is labeled with the git commit from which the build came — it’s the long checksum in the “Task” line.

The package may not be there anymore, but that git label is all you need. It represents the position in the repository history from which the packager built that package. You can find that point in history and re-execute the same steps. You can then clone the package’s git repository, reset the HEAD to the proper commit, and send a scratch build to the Koji builder. Once the build is done, you can download the results.

Caveat: It’s possible that other package changes in Fedora might make a build of that exact point in history difficult later. Be aware this solution isn’t perfect, and you may simply want to find an alternate build in Koji that still exists and suits your purpose, or use the latest updates-testing or stable package instead. But in the hopes people find it useful, here are the commands, assuming the package name is “foobar” on Fedora 16 and the git commit of interest in starts with “0123abcd” (and let’s hope I do better than in the last post in which I gave tips):

su -c 'yum install fedora-packager'
cd /tmp
fedpkg clone foobar
cd foobar
fedpkg switch-branch f16
git reset --hard 0123abcd
fedpkg scratch-build
The URL that comes back to your console is the task for that build, and you can use that to drill down into the individual package build tasks as needed later. Remember, scratch builds are not retained for very long, so if you want the package, try to download it relatively soon after you build it.

Here’s another hint: the git reset command above rewrites your index and your working tree, so essentially you “lose” the later history of the repository. However, git is so awesome that this is not a permanent condition. If you really need to reset the git repository back to its original path, you can use git reflog to find the reference to the checkout you did of the “f16” branch, and reset to it (probably something like this):

git reset --hard HEAD@{1}
Once again, it’s important to point out that the above is not for the faint of heart. If you don’t understand the ramifications of trying withdrawn, obsolete, or deleted packages on your Fedora machine, or packages intended for testing, don’t use them. That being said, testing packages is a really helpful activity, and there are all sorts of easy ways to keep testing contained on your system, such as using virtual guest machines. So the intrepid needn’t be shy!

Snake for great justice.

I took some time last night to make a couple additional fixes and changes to the irssi-libnotify project I posted about a few days ago.

Among other things, I changed the upstream VCS from Subversion to git, which ended up being pretty simple. I’m much happier keeping the code at Google when I know the entire history resides with me, too. That way, I can move the upstream elsewhere if it becomes necessary. Thankfully, git-svn makes it incredibly easy to migrate, and there’s a helpful wiki page to help with the migration.

I did find that the site docs left out an important part (to me) of the process, which is migrating the authorship information properly. This page was useful to find a quick recipe to use with the SVN log.

For some reason, though, I was still on a hacking (or more precisely, “flailing”) kick. I was happy to have made some fixes to my project, but I’m not a big fan of Perl, so I checked out the current state of irssi-python. This project, as you might expect, provides a Python scripting interface for irssi.

Unfortunately, the project hasn’t kept up with irssi, so it isn’t easy to build. I found a patch for 0.8.15, which applied cleanly and got most of the way there. However, I found for some reason that upstream irssi doesn’t install some of the development header files needed to build irssi-python. I created a patch and a new SRPM that will allow the project to build properly, and also put my work in a git repo with a README file that will help you build it if you’re interested.

Once you install the plugin, you can do the following to experiment so you can build your own scripts:

/load python /py exec import irssi

Have fun!

Let’s not be too hasty.

In a recent post tech writer Sean Michael Kerner advocated moving the kernel to Github. Here’s why I think the evidence isn’t so clear cut. Note this is my personal opinion, since I’m not a member of the kernel developer community and thus have no real say in the matter.

Kerner writes, for example, “Having Linux on Github also means that Linux benefit[s] from the security, management and infrastructure that Github already has.”

While Github may be a fine service (I don’t use it so I can’t say one way or the other), it’s also a commercial service. Github has no incentive to report security problems, whereas kernel.org is run in a more transparent fashion. Even though the kernel.org administrators were unaware of the attack for some time, once they did discover it, they acted quickly and with full disclosure to the community. That transparency is an important part of the open source process, and it cannot be automatically expected from Github — which makes moving the kernel project there a non-starter for the community as far as I can tell.

That’s completely aside from there being no factual information on which to base any assertion of Github’s level of security. Github may have a fine security record, or perhaps it’s not spotless. Without any transparency in the management of the system there’s no way to tell. One can’t definitively say things would be better there than on kernel.org, so part of the reasoning for a change doesn’t hold water.

He also argues that the interface on Github makes the code easier to browse and work with for normal humans. My question is, how many normal humans really work on the kernel? And maybe another question is, how many normal humans do we want working on the kernel? I’m really happy that the people who work on the kernel are crazy space aliens with ten fingers on each hand and three extra brains where most normal humans have a left lung. Well OK, maybe that’s an exaggeration, but they do all seem to be somewhat beyond human when it comes to dealing with the minutiae needed to understand, write, and fix kernel code. So again, I don’t see how a move is necessary or helpful.

Regardless, I’m glad people are interested in the security of the kernel. What’s great is that Linus and friends built exceptional security right into git itself. Because every object, every commit, and every step in the history of the repository is represented by a cumulative cryptographic one-way hash, it’s about as easy to insert bad stuff into the kernel as it would be to suck the entire atmosphere of your office building into the next one over with a soda straw.

As long as websites have visibility or high profiles, they’ll be targets for evil system crackers. (By the way, boo hiss to the ones responsible for the evildoing in this case.) Moving from one place to another doesn’t mean cracking attempts would stop. The only thing I can see happening is that the kernel community would have less insight into their security footprint. I believe you need better reasons to move a big FOSS project somewhere other than the place you’ve accumulated thousands of contributors, and I just don’t see those reasons in Kerner’s post.

Disclosure: I’ve met Sean Michael Kerner, have spoken to him on many occasions, and find him to be a good writer and a nice human being. So this post in no way impinges on his professional standing. I sometimes agree with him, but not in the case of this particular article.

This week in fast forward.

I flew up to Red Hat’s office in Westford for the week to accomplish quite a large number of things, mainly a metric ton of meetings with my manager and a few other people around the department in relation to my new role at Red Hat. Therefore my schedule’s going to keep me quite out of touch throughout the week. Of course my email will work and I’ll be online quite a bit, but my appearances will be somewhat of the “jump on, jump off” variety.

I feel a little ashamed this is my first blog post in over a week — especially given the subject matter in my last post. Last week went by so fast my head was spinning by the end of it. (Fortunately that stopped before I went to skating lessons on Saturday morning.) I’ll try to write something substantive tomorrow, especially regarding some cool stuff we’ve been doing with Fedora Insight. I bought a bunch of Drupal books and have been trying to study up on this very cool framework, although this week will really put a crimp in my progress.

I did get to hunker down over a little work on the plane, and thanks to git I was able to contribute some work to the Websites team, and help them make the new website even more translatable by our translator teams around the world. Nice to be able to accomplish something that helps other people while I’m stuck in a flying metal tube!

FAD Fedora Talk 2009, Day 2.

Today started with a bang — or maybe it didn’t. I don’t know, because for the first time in something like two years I managed to oversleep, missing my alarm clock by over an hour. That meant rushing around like crazy to get Ian up — actually Eleya did this, bless her heart — and get myself ready too. I ended up about a half hour late to pick up the folks for the FAD, although I did manage to SMS everyone to make sure that first, they knew I was on my way ASAP, and second, they let the folks on IRC know since I couldn’t get in front of a keyboard while making up any time.

Fortunately, everything worked out OK — we were at BusinessPlayce by 9:30am, and since we had been able to leave some of our equipment there overnight, thanks to the awesome Paul Delagrange, we were able to spring right into action. Jeff Ollie and Jared Smith immediately got to work on the Asterisk streaming and recording bits, Ian was back at work on his web front end, Jon Stanley was cobbling away on the various problems we’d found in our troubleshooting docs, and John Poelstra and I started working on updating all the use cases linked from our game plan.

By lunch we were well on our way to having on demand recording and streaming starting and stopping, along with reminders being issued in the call and to each new caller coming to the conference. This latter part is obviously useful since by law callers need to be aware that they’re being recorded not only at the beginning of a call, but also if they join partway through. Jared Smith also has customized Fedora Talk so that one can call an extension from a registered client to record a personalized name for one’s extension.

We did encounter some bugs in the latest Asterisk, but thanks to the fact that Jared runs with their developer crowd, we already have bugs filed and hope to receive fixes in the next update that will take care of some of those issues. I worked quite a bit on trying to put together a more logical workflow for the Fedora Talk web site, and I’ve put a copy of that work — a little further along than the one Jon Stanley kindly posted earlier — at my fedorapeople.org space. (It’s also in the fad-ftalk branch of the fedora-web git repo if you’re interested in helping.)

Today we started with one-hour blocks but again our hard time limits didn’t work as well in the afternoon as we cross-collaborated some. I think the blocks of time might be more effective in an environment where the various teams working on sprints at a FAD are separated from each other. That unfortunately lowers the ability to get ad-hoc questions answered quickly, but I suspect it would also allow people to be less distracted by different conversations. Personally, I like both ways of working and don’t think our output suffered badly, although I’d eagerly try a more rigorous approach just to compare and contrast them more easily as an experience.

We have a large output of work to point to in the way of tickets opened, tickets closed, work done, and notes taken on our wiki. I think we probably went from a state of about 20% done on this whole system to something like 80%. One of the big pieces still left is to make sure everything on the asterisk2 server gets correctly “puppetized” so that it can be recreated from bare metal if required. Our Infrastructure team makes very extensive use of Puppet for just this reason.

I found that hacking on the web site was quite enjoyable and I am feeling a little more familiar with git overall since I’m starting to use it more regularly. It’s nice to take some time to work on purely enjoyable technical work, but also to do it in a situation where people are collaborating and enjoying each other’s company too

After the FAD ended at 6:00pm or so, we packed up quickly and headed to my house, where Eleya had prepared an unusually hearty meal for everyone — a big roast beef dinner in the best style of “low country” cuisine. She called it a warmup for Thanksgiving, I called it delicious! Then we took a semi-break from keyboards and LCD screens to play some Rock Band in the basement on the home theater, complete with a lot of smiles and laughs. I got everyone back to the hotel by 11:00 and then headed home to do a bit more web cleanup and write this blog.

Tomorrow morning, I’ll be waking — on time! — to take Jon to the train station in Fredericksburg, Ian and Jeff to the airport in Richmond, and then John Poelstra to the Richmond train station since he’s heading to RDU for a few days before he heads home to the other coast. Hopefully I should be home by around 3:00, at which point I suppose I’ll stiffen my upper lip and plunge back into my inbox, which I’m pretty sure is overflowing by this point.

It was another in a line of great Fedora Activity Days, and I want to thank Max Spevack of Red Hat’s Community Architecture team for giving us the funding to make it happen; John, Ian, Jeff, and Jon for traveling to Virginia to put in hard work on a precious weekend; Jared Smith for providing a ton of equipment, expertise, patience, and just plain good humor and good nature; Digium for their support in goodies and hardware; and Paul Delagrange of BusinessPlayce for hosting our hackathon.

UTOSC 2009, Day 3.

I’m sitting in the pleasant (and free wifi-equipped!) Salt Lake City airport, waiting for my plane back to DC and my home and family. I’m really looking forward to seeing them for dinner and a few hours of together time, before I motor off to Raleigh early tomorrow morning.

Yesterday was the final day of the UTOSC 2009 conference, and it was set aside as a “Family Day,” just like last year. And as with last year this was one of my favorite days to be at the conference. Not only were there lots of cutie-pie rugrats running around the area, but we had goodies galore for them — buttons, stickers, and temporary tattoos, which they made off with by the score.

I spent part of the morning helping Mark Clanton get his new Compaq laptop loaded with Fedora 12 Beta. Because someone removed the httpd binary from the second stage installer, I couldn’t play the neat trick I used in earlier releases. I worked around this unhappy situation by having a Fedora 11 DVD ISO available on the installation source, a USB hard disk, and loop mounting it and its contents in succession to get to the old httpd binary in Fedora 11’s second stage installer.

Of course, if we’d waited for the actual Beta release we could just use a standard DVD, network URL, or NFS installation, but where’s the fun in that? Everything worked out in the end and Mark also has all the kernel mode-setting bling provided in Fedora, from a beautiful graphical boot with Plymouth to a smooth fade into the login screen. Nice!

I worked on a couple tasks for the upcoming release, such as updating the press briefing sheet we send out with our Fedora 12 Live USB previews. I also caught upĀ  with Adobe’s open source director to talk to him briefly after his keynote, and of course spent a good amount of time at the Fedora booth talking to families about Fedora, open source, OLPC, and Sugar. Larry Cafiero was Johnny-on-the-spot with T-shirts, making sure everyone could show off Ian Weller’s new “splatter” design — and of course their love for Fedora and free software!

In the afternoon I actually made it to a talk, which ended up being a two-hour workshop on advanced git. It was paced and positioned perfectly from my perspective, given by Tim Harper, a great instructor and an experienced Rubyist, not to mention a super-friendly guy. I got so much out of this talk, it almost seemed like the whole trip was worth it just for those two hours.

By the time I returned from the talk, I found that Larry and Ian had already spirited everything from the booth back into boxes and bins, and it was ready to be shipped off to the next great community event Fedora is attending. Ian and I talked about some FUDCon travel subsidy matters, which Mel Chua and I are working on finalizing, to bring in more community members. Then it was time to say goodbye to all my UTOS friends and thank them for another amazing conference.

Once again, UTOSC has grown from the previous year, and I would safely say that it is now one of the best-organized, most successful and well attended community conferences in the USA. A great assortment of community spokespeople, users, developers, business owners and entrepreneurs, and system administrators makes this a can’t-miss event for networking, learning, and just plain fun. My hat’s off to you guys, UTOS, for a wonderful UTOSC 2009. I’m already looking forward to UTOSC 2010!

So that’s where I put those spare minutes.

Things accomplished so far this weekend:

  • Held a FredLUG meeting, except none of the new folks showed up — probably a combination of Saturday morning and ugly weather. Two of them have won some nice giveaway schwag, though, so I expect we’ll see them at a meeting soon.
  • Watched the weather turn from rainy to unberably humid, back and forth several times in succession. Yay.
  • Worked on Release Notes repository, mainly getting the notes building with the latest Publican. I found some discrepancies that will take a tiny bit of release engineering retooling on the side, hopefully nothing horrible. Once again I failed miserably at figuring out why anyone would think that running sed-ish Perl scripts is a good substitute for proper XSLT. More collaboration would have helped a lot in publican’s development, IMHO. In championing this tool as a way of increasing that collaboration, I feel like I might also be shooting the Docs Project in the foot. We still have time to revert to our previous toolchain if needed.
  • Did some expense reports for the office, which are a PITA but a necessary evil.
  • Learned some more about git, by paying partial attention to some videos that RSS was kind enough to throw in my direction.
  • Installed a new showerhead in one of the upstairs bathrooms. Hopefully this will save some water, but my ulterior motive came from having to shower in that bathroom while our master bath was being restored this summer. The original, crappy, contractor-grade showerhead was still installed there, so I decided to do away with it this weekend finally.
  • Worked with Evie on some extra math enrichment stuff from her second grade class. She’s pretty much a pistol at everything so far. Some of the problems were subtraction, so when it came to a problem like “34 – 19,” I asked her in mock surprise, “Uh-oh, how do we handle four minus nine?”, and she answered matter of factly, “That’s negative five, Daddy.” (Next up, algebra.)
  • Got the book Snake Wrangling for Kids installed on her OLPC XO, which she’s already enjoying.

I also found out how to do some pretty boss CVS importing to turn some of the Docs content into git repos.