Lars Wirzenius: November, 2006
Contents
- November 28: Usability design for hungry users
- November 27: IRC mugshots
- November 24: Bzr book outline
- November 02: Something Positive and vocal minorities
Tuesday, November 28, 2006
Random thought: Usability design for hungry users
As I write this, I'm very hungry, not having eaten anything for 16 hours or so. I just clicked on the wrong button in Xchat, changing user modes the wrong way. No biggie, it was easy to fix. It still prompted me to realize that user interfaces need an automatically triggered mode to handle users that are hungry, tired, drunk, or otherwise less than accurate with their mice.
Monday, November 27, 2006
Random thought: IRC mugshots
On big IRC channels, it'd be easier to remember people if it would be possible to attach a picture to the nick. Something like this would make a possible implementation without changing the IRC protocol: one could define a URL pattern for each network and channel, and the client would look up the picture using the pattern. So for #debian-devel, I could have a pattern http://planet.debian.org/%s.png, and then the hackergotchis would be used, if they existed. (Later, perhaps, a http://mugshots.debian.net/%s could be created, for all Debian people.)
I've no idea how to present the pictures in the UI properly, without making the text lines too sparse. I'll leave that for someone else to figure out.
Friday, November 24, 2006
Random thought: Bzr book outline
While cleaning up my hard disk, I found the beginning of an outline for a book on Bazaar (bzr), the version control system. I wrote it one weekend this summer, when I felt I had lots of free time. I don't, and won't, for the foreseeable future. Therefore I'll dump the outline here in my web log, so that perhaps someone will be inspired to write it for me.
The Bazaar distributed version control system
For most of the 1990s, the free software world relied on CVS for version control. It was the best free system for the purpose. During the early 2000s, a number of new systems started getting into public knowledge. One such system is Bazaar. This is the outline for a book to explain how Bazaar is used in different kinds of scenarios. The book is not a reference manual: the software's own documentation is best suitable for that; this avoids having to constantly update the book.
The book is structured as a series of case studies of common scenarios, starting with the simplest one, and getting increasingly more complicated. This approach allows the reader to quickly learn the things they need for a particular kind of situation.
Introduction
This chapter explains what version control systems are, and gives a summary of their history so far. It explains various basic concepts, such as centralized versus distributed, but briefly; these will be expounded on later in the book. It compares Bazaar to other well-known systems. It explains the cumbersome naming history of Bazaar. It explains how to install Bazaar by referring to the website and to the package repositories of various Linux distributions.
Quick overview
This chapter is intended for those with some experience with other version control systems, such as Subversion. It gives a quick run-through of the central concepts of Bazaar, and how to do common tasks on the command line.
The web page project
This is the first case study chapter. It explains how to use Bazaar to keep track of changes to a web site. A web site only changes linearly: only one version exists at a time.
My little program
This chapter explains how to use Bazaar to maintain the source code for a one-person programming project. The program has a stable version, which gets bug fixes, but no new features. There is also a development version, which gets the new features. Sometimes a bug needs to be fixed in both, and Bazaar can help with this.
Additionally, sometimes it is not clear whether a new feature can be implemented cleanly, or there are several possible approach to how it can be implemented. Thus, the chapter also explains these so called feature branches.
Further topics for this chapter include making releases, and using repositories to avoid excessive disk usage.
Tight teamwork
This chapter explains how to use Bazaar when the one-person program becomes an internal project in a company, with a well-defined set of developers. Thus, we discuss how to set up a centralized branch in a way that all the developers can commit to it.
Distributed free software development
This chapter concentrates on a typical successful free software project, with contributors from all over the world, and the problems that this involves. Thus, we discuss how to publish a branch for anyone to see (but not change); how to share changes (patches/bundles) between developers; how to co-ordinate the development of the whole project (at least from the version control point of view).
Switching a project to Bazaar
That's it. If you write it, please send me a note when it's published so that I can get a copy. Thanks.
Thursday, November 02, 2006
Debian: Something Positive and vocal minorities
R.K. Mulholland, author of Something Positive, one of my favorite web comics, writes something that seems pretty relevant to Debian:
People assume most Debian developers are heavy-handed, pushy, intolerant bigots bent of dominating any other culture or idea and supplanting it with their own whims because, for the most part, the ones who speak up the most ARE heavy-handed, pushy, intolerant bigots bent on dominating any other culture or idea and supplanting it with their own whims. It sucks. It's horrible. And it's the what everyone of any faith, political idea, or lifestyle has to deal with. People always focus on the loud minority who ruins everything. And like any other group, the only way you can combat this is making your views and, in this case, your kindness and actual testimony louder than the hateful prattle of those hurting your beliefs.
Mulholland actually writes about Christians, but I took the liberty of substituting the words "Debian developers" instead.
I wonder if I should reconsider my policy of shutting up and going away when people start quarreling or otherwise behaving badly inside Debian. Perhaps participating more actively in such a situation would be helpful, if only to make it clear that those most vocal do not always represent the majority.
Mostly such participation should be to do constructive things: offering solutions to technical problems, pointing out good things others do.
Sometimes it would have to be to help Debian make some of the very difficult decisions it needs to do. For example, what should the project do in the case of Sven Luther? This is a good example of a problem that Debian as a project is very ill equipped to handle.
I'm not sure I will do anything about this, but now that it's two hours past midnight, I feel I should. When I wake up, I expect to regret this.