This was taken in Hockley Valley Provincial Park on a trail hike 2 weeks ago. We found a tiny river running along the trail, the river was mostly covered in ice, but in places we could see bubbles forming under the ice from the running water. Just before the river and the path diverged we saw this crack in the ice with the beautifully crystallized ice.
We’re going to release a new version of the ChangeLog plugin to the Fedora Core 5 update repository tomorrow. This update has some bug fixes with the formatting of the ChangeLog when one person tries to do consecutive commits. This version has been sitting in the update site for a few days and there haven’t been major complains, so if testing goes nicely tomorrow, I’ll push it to the updates repo. I’m also planning to try and get some new functionality integrated into the ChangeLog plugin if I have time over the next few weeks.
I’d like to get it playing nicely with the Compare editor because I find that most of my ChangeLogs are written up while inspecting changes in the Compare Editor. I usually go through the files, see what I changed and write entries. Right now I have to go through:
right-click -> Open with Editor -> Ctrl+Alt+C
I should really be able to do Ctrl+Alt+C from the compare editor at the very least. In the best case scenario I’d like to go through the diff and see what functions changed, and have them all put in the entry stub (possibly providing an option for just using the filename instead).
Last weekend I finished reading Karl Fogel’s Producing Open Source Software: How to Run a Successful Free Software Project, which took me about a week to read on the subway to and from work. First off let me say that this is a great book and I recommend it to anybody who works on, with, or uses Open Source Software extensively. Karl Fogel knows what he’s talking about in this field, as he was an active developer of CVS in 1994-1995 and later on started the Subversion project for CollabNet, where he still works.
The book talks little about the actual practice of programming for an Open Source project, instead focusing on producing as the title suggests. In Fogel’s mind producing means much more than just the task of programming. It includes the political and social aspects that inevitably surround every open source project, as well as management skills essential for leading such a project. One of the greatest strengths of the book is that it takes many accepted unspoken practices and beliefs that can be observed in the open source community and brings them into the open in a very straightforward way. This is very useful since even people who’ve worked with open source for some time often don’t have a full understanding of the ecosystem. Although the factual content of the book is useful to those who don’t know much about open source, I feel like the major attraction here is the consolidation of Fogel’s experience into a clear and concise narrative. This gives the reader a much more interesting and analytical perspective on the world of open source than she would have from a mere familiarization with the facts.
The book starts off by talking about the history of the Free/Open Source movement, mentioning all the major events and players. This is a good introduction for someone who is new to the scene, and might also fill in some gaps for those who don’t have the full story, but those who are fairly well versed in the historical aspect may want to skip this section. The book goes on to talk about the beginnings of an open source project from inception to the opening up of the codebase. Fogel mentions various details that would help start a project off on the right foot. Unfortunately most of the interactions people have are with existing projects, so this is somewhat of a niche need. The third chapter talks about the technical infrastructure needed to run a project, I feel that this chapter goes into too much details of running and maintaining various software components such as mailing list, something that would have fit better in an appendix. You might want to skim over this one if you’re not starting a project next weekend. The fourth chapter talks about political and social structure, touching on various forms of governance and decision making. This is a very important chapter and gives a much needed perspective on the various options a project has, some of which might not be as obvious as they seem. Chapter 5, Money, is targeted towards a manager of an open source project, or a team that must work on an open source project, but is useful to everybody. This chapter opens up one of the areas that are sometimes considered taboo by some open source hackers, what to do about money (or lack thereof). Fogel takes a very practical perspective, stipulating that businesses often gain from open source projects, and thus often invest in them. There is nothing wrong with investing in a project by either hiring outside help, providing money to some of the existing contributors, or helping to fund infrastructure needs. Fogel explains some of the tradeoffs and touches on the importance of always making sure to approach the matter in the appropriate political way. Chapter 6, Communication, is something that should be a must-read for anyone who participates in a mailing list. Some points are pretty obvious, but some of the techniques of handling difficult situations can only be learned from experience and can be difficult to hone down. Chapter 7 talks about releasing packaging and developing software and is a useful read for understanding how open source projects go about doing this as much as for learning how to do it yourself. It’s a useful introduction to some of the more common practices of doing things, why reinvent the wheel if you don’t need to? The next 2 chapters deal with managing volunteers and choosing the right license. They are both very useful to anybody who is starting an open source project or is in a position to take on the lead or management of a project. They are not as useful to the user of open source software. The end of the book also contains a useful list of software for various purposes such as bug tracking and version control.
The book is very readable over all, and can probably be read over a few days. The author does a good job of splitting up the topics, even thought this is not always an easy job, allowing the reader to skip over sections without losing herself. Fogel also does a good job of referencing the abundant online material surrounding his topics of choice, especially when it comes to sending the reader to search for a more detailed factual account.
The one piece I felt was missing from the book was a comparison of some of the major organizations that engage in producing Open Source software and their practices. I would have liked to see a chapter or appendix comparing Apache, GNU, Eclipse, CollabNet, and perhaps some others in some of the aspects that the book covers, such as organization of power, decision making, commit access and other privileges. This would have been useful for anybody who has some experience, but does not have enough experience to be able to make these distinctions off hand. A reference to existing works making such a comparison would also be useful.
Despite these minor nitpicks, this is a great book. True to the open source spirit, the book is also available online at http://www.producingoss.com. But supporting the author by buying the book is very worthwhile for such a great book.
Author: Karl Fogel
Title: Producing Open Source Software: How to Run a A Successful Free Software Project
Publisher: O’Reilly, 2006
ISBN: 0-596-00759-0
Taken last weekend on a frozen trail hike.
Yesterday I uploaded a new update site, made by Jeff Pound, for the Eclipse plugins we ship in Fedora. We now finally have both the ChangeLog and Bugzilla plugins in the same update site, which should be much more convenient. The main problem that we’re seeing with this is that we currently do not support the 3.2 builds, only 3.1.x, this is because the plugin depends on a patched up org.eclipse.compare plugin. The patched version exposes API that is internal in the official Eclipse.org version, and this allows us to apply patches from bug reports to projects in the workspace. Unfortunately these patches by Jeff were largely ignored by the core Eclipse folk, and are not committed to the 3.2 branch. On top of that the code that the patch applies to is still changing, since it’s internal API that the patch exposes and is not covered by the API freeze. So for now we are only supporting Eclipse 3.1 in the Bugzilla plugin. In the near future we may branch it so that we have a cut down version without the patch functionality for 3.2 (which is not that huge of a deal anyway). But we still need the internal API to stop changing for this. I guess we’ll wait and see.
Yesterday Pat and I made screencasts for DrProject, these are available here. We used Wink for the screencasts. Unfortunately version 1.0 of Wink doesn’t support sound throughout the cast, and you can clearly hear my lovely voice in those screencasts 
. That’s because we used the 2.0 beta of Wink, which is currently only available for Windows. I have to say that from doing a few of these I get the impression that Wink really rocks! The cruft of doing a screencast took only a tiny proportion of the time that we spent on the whole deal. 90% was spent on figuring out what to say, and trying to do it without hysterical laughter. Right on Wink. I’ll be waiting patiently for this tool to come out of beta so I can use it on Linux.
After much tweaking of the content for the renovated Fedora Eclipse website, it is finally up on the web. Thanks to Diana Fong, our very talented graphic designer, for the very nicely done design. I think this is miles better than our previous page, which had very little information. We now have separate pages for the different plugins, so we can have some info on them. The next important step is to migrate the Bugzilla plugin’s update site into the sourceware.org server, which I will hopefully do tomorrow. This should make the Fedora Eclipse effort much more visible, and allow people to communicate with us better. Let me know if you find any problems with the site.