Something I want to add to a post by Slyvian LeGall - motivation does not have to disappear during the wait.
I was lucky, my advocate is project-lead for a Debian sub-project (Emdebian in this case) and I was able to contribute to Emdebian before my DD status was completed. This included uploads to Emdebian that Debian people could use. It included policy decisions, infrastructure development and programming of bespoke utilities.
i.e. my interest was maintained because I had an outlet and an encouraging, supportive, advocate.
When a DD advocates a particular person in NM, there should be some common ground, some experience of working with that person and it should be possible to find a way to maintain a working relationship within that environment.
My experience of the end of NM was one of increasing responsibility, increasing activity, increasing motivation and constant affirmation and assistance from my advocate and others in the sub-project.
So a big thank you to Wookey and debian-embedded in general. It bodes well for the other prospective DD's currently being mentored and encouraged through NM within Emdebian itself.
(Mind you, my NM timescale shows that I didn't wait anywhere near as long as the current delays.)
I fully appreciate that the horrendous delays currently being inflicted on people in NM and upon Debian in general are abominable. If there are ways that existing teams in Debian can adopt and encourage these prospective developers, it can only help in keeping these people interested. It may be a more productive way of helping with the NM problems than just carping on a blog.

Yes I know, it’s like a year since the last development release of Backup Manager has been published, I should be ashamed of such a huge idleness. But actually, If you ask me, I’m not. Instead of writing long lines of haiku to apologize for being so late at releasing, here is an illustrated reason why it was so loooong.

Yes I know, it’s like a year since the last development release of Backup Manager has been published, I should be ashamed of such a huge idleness. But actually, If you ask me, I’m not. Instead of writing long lines of haiku to apologize for being so late at releasing, here is an illustrated reason why it was so loooong.

I got my FON router delivered to my house about 2-3 months ago, but I didn't realize what it was until I was cleaning up my office to leave for Buenos Aires. Glad to have a project, I set it up on my home network while I was waiting for the taxi to the airport. I've only really started playing with it since we got back. FON is an international effort, originally based in Spain, to share extra network capacity with roaming wireless users. You set up a router in your home (or wherever), and any other FON user can connect to the Internet through your network. Conversely, you can connect on any other FON network. There is a lot of grass-rootsiness to FON, but it's a commercial project, which turns some people off. I originally heard of FON at Wikimania 2007, where FON provided wireless routers for each attendee's room. It was a nice service, although the doubled-up ESSIDs were kind of confusing at the time. They make a lot more sense for home use. I was impressed by how many FON spots there are on the Montreal/Plateau (see http://maps.fon.com/ for details); about one ever 2-6 blocks in any direction. I think there's an opportunity here to see a higher concentration, though. I'd love to see co peration between FON and, say, le Sans Fil, possibly involving the Ville de Montr al. Apparently there are already FON cities in different parts of Europe, so it's not impossible. I think FON is an interested development for WiFi -- a hybrid between community-based initiatives and a commercial venture. I'm not sure if it will be successful, but I think it's a step in the right direction. tags: fon wifi wireless network

Steve Kemp writes about security issues with C programs [1]. It seems obvious that if you are going to do something that is overly tricky (such as anything related to setuid programs) then you should have a good knowledge of what you are doing. Steve goes a little further and suggests that anyone who doesn’t know C should not package a C program. Andrew Pollock is a Debian developer who doesn’t program in C and yet packages some C programs, he explains why he thinks that it’s correct to forward C coding bugs upstream [2]. In this debate I have more sympathy for Steve’s position. Security is one of the most important things in software that we develop, if you can’t develop secure software then IMHO you shouldn’t distribute any software. Although it should be noted that the two posts in question don’t directly conflict. Steve’s main point (your should know the code well to do something relevant to security) does not directly conflict with Andrew’s main point that a non-C coder can maintain the Debian packaging files and forward bug reports related to C code upstream. In the more general case it’s often impossible to know all languages used in a project. It’s not uncommon for a single project to have core code written in C, a configuration file format (which is a programming language), a Makefile (GNU Make is a fairly complex interpreter), Autoconf/Automake (even more complex tools for creating complex Makefiles, and then some Perl or Python to manipulate input or output data. The SE Linux project has code in all those languages plus the M4 macro language. It seems obvious that in a large project the number of people who are capable of understanding all languages which are used is going to be a small sub-set of all Debian Developers. It also seems likely that someone who knows some of the languages really well may be capable of doing a better job than someone who has a passable knowledge of all of them. For the vast majority of my work in Debian I have been a member of the upstream project in question (for Bonnie++, Postal, Portslave, Maildir-bulletin, and logtools I’m the sole upstream developer). Often I start maintaining a package with the intent of doing the minimum needed to keep it maintained in Debian but then end up doing upstream work, for example I briefly had write access to the CVS repository for pppd when I was maintaining it and I had write access to the KDE CVS repository when I was working on KDE packages (which incidentally was before I became an official DD). When I first started working on the SE Linux project I aimed to merely package the code in question for Debian. I was not planning on spending seven years doing upstream work! When I’m working on a project I spend my time working on the things that most need attention. That often means that I get diverted from Debian packaging bugs (which are often minor issues) to work on upstream bugs. In many ways my work practices make me a Debian user and upstream developer who also does Debian packaging rather than a dedicated DD. This of course does have a detrimental affect on the quality of my Debian packaging work - but overall I believe that it’s best for the users! As an upstream developer who is focussed on Debian there are significant advantages in being a DD. I can immediately upload a new package to Unstable without any delay, and there is the potential to take over a related package (either be given the package or NMU) if it’s the best way to get around a roadblock. Another benefit is that in certain limited situations I can speak on behalf of Debian (in terms of packages I “own”). When it comes to upstream development of SE Linux I can make decisions about how things will be done in Debian and work with other upstream developers to ensure that cross-distribution compatibility works reasonably well. It seems to me that a fairly ideal process for managing Debian development would have the people who are capable of the hard coding doing so and some people who haven’t got specific coding skills working on the packaging. I would be very interested in receiving patches related to the Debian packaging of the packages I “own” (in Debian it’s widely regarded that a man’s package is his castle) so that I can spend more of my time on the C coding. I’m not bothered about NMUs (a Non-Maintainer Upload - is when someone else uploads a new version of one of my packages to fix a bug). If anyone would like to NMU one of my packages they are welcome to do so as long as there is a suitable combination of bug urgency, simplicity of the fix, and lack of response from me. If someone wants to start NMUing my packages to fix bugs reported by the latest version of Lintian in Unstable (Lintian is the Debian tool to automatically check for packaging bugs) then that’s OK. Of course there are a variety of other situations that DDs sometimes find themselves in. There have been situations of overtly hostile upstream developers. I try and avoid associating with people who have certain difficulties in interacting with others. If someone is going to change their license and try to back-date the change or create a license that makes it difficult to distribute modified versions of the code then I’m inclined to avoid even using the software, let alone being involved in developing it. This means that the software that I use in any serious way has reasonable people doing upstream development who welcome new people to join their work.

• [1] http://blog.steve.org.uk/adopt_a_less_marital_tone.html


• [2] http://blog.andrew.net.au/2008/04/12#packging_requirements

Share This

This is the third plugin I have been working on for Rails - It's the one that still needs most work to be fully usable (for what I originally envisioned it), but is almost there - I have not touched it (nor the other two I recently presented here, acts_as_catalog and Real FK because real-life has demanded my time on various other fronts.
Anyway, this is IMHO the most interesting of the three plugins I've written so far.
So, following what I did with the other plugins: You can go to acts_as_magic_model's main page, or jump straight to its SVN repo. And the basic description follows:
Rails plugin to allow for extensible models, where inter-model relations are inferred from the database's structure, and not necessarily from explicit declarations in the models.
This means, when one of your models acts_as_magic_model, this plugin will try to infer all the basic relations (has_many, belongs_to and has_and_belongs_to_many) its base table has with other tables in the database, adapting the model correspondingly. Using the plugin In order to use this plugin, you only have to declare it in your model. As an example, say you have the proverbial project-management system, where you have projects (each of which can be of several different types) and people, and a HABTM relation between people and projects. So, you have the following tables (expressed as migrations here):

    create_table :people, :force => true do  t 
      t.column :name, :string
    end
    create_table :project_types, :force => true do  t 
      t.column :name, :string
    end
    create_table :projects, :force => true do  t 
      t.column :name, :string
      t.column :project_type_id, :integer
    end
    create_table :people_projects, :force => true, :id => false do  t 
      t.column :person_id, :integer
      t.column :project_id, :integer
    end

Using acts_as_magic_model, you can skip declaring the relations in your models, like this: (of course, each of the classes still has to be declared in its own file)

    class Person < ActiveRecord::Base
      acts_as_magic_model
    end
    class Project < ActiveRecord::Base
      acts_as_magic_model
    end
    class ProjectType < ActiveRecord::Base
      acts_as_magic_model
    end

And the gaps will be filled in for you - that is, you can go on and ask for Project.find(:first).people, ProjectType.find(:first).projects.size, Person.find(:first).projects.map pr pr.project_type , and whatever you fancy.
In future versions of the plugin, I expect even to get rid to explicitly declare the class declarations.
Of course, you should be warned: Initializing a model using this plugin is quite database-intensive. It will clutter your logs, and it might be unbearable if you use it in development mode. Still, its convenience is very often worth it.
Its main uses should be when prototyping and when designing a system that needs to be flexible to the data models themselves - If you don't expect your system's data structures to be highly malleable, you should probably use acts_as_magic_model only as a prototyping aid.

There have been a number of discussions on sane-devel in the past months revolving around the SANE2 standard (still in development) and/or extensions to the current SANE1 standard. SANE2 is an effort that has been “ongoing” (on and off, mostly off, unfortunately) for a number of years already. This led to a number of questions being raised, most notably this one: do we need SANE2, or can we get away only with extensions to SANE1? Or should we just redesign the whole stack from the ground up?
This matter is undecided as of yet, but extensions to SANE1 are planned, being discussed or in the making for some of them. During the discussions, a fork of SANE has been announced, dubbed “SANE Evolution”. No idea where that is going, but it’ll probably end up being merged back into SANE in the end. So, in a nutshell, things are moving again (albeit slowly), which is good news considering the project was mostly asleep in recent times. To celebrate that (and because I now have total control over my free time again), I’ve been working on the network side of SANE again. In 2 weeks (3 week-ends, roughly):

• saned has been turned into a regular, full-fledged daemon
• mDNS/DNS-SD service announcement & discovery has been added to saned and the net backend (using Avahi)
• I have 20% of a WireShark dissector for the SANE protocol written, and already spotted (and plugged) an information leak bug in the net backend thanks to it

Turning saned into a regular daemon made it possible to clean up a good chunk of the code duplication that was introduced by my previous AF-indep/IPv6 work; the startup code is readable again. The Avahi support is (I hope) a very nice thing as, when enabled, configuration of the net backend on the client side is no longer needed. This is an experimental feature still and as such it’s disabled by default at build time. I have a couple of ideas to improve that feature, but this means saned will have to evolve even more so it’ll take some time. The WireShark dissector is a tool for working on enhancing the network protocol. It proved useful already with the information leak I spotted with it (though it’s minor). It’ll be a long work to extend the network protocol and implement that into saned and the net backend in a backward-compatible manner.

Acme::Eyedrops allows you to 'design' your Perl programs (if you have any; you'd better not). Basically, given a Perl program and a "shape" file, it produces a perl program that visually resembles the given shape and behaves like the former program. Here's my favorite example:

    ''=~(        '(? '        .(' '         '%')        .('['        ^'-')
    .(' '         '!')        .(' '         ',')        .'"'.        '\\$'
    .'=='        .('['        ^'+')        .(' '         '/')        .('['
    ^'+')        .' '        .(';'        &'=')        .(';'        &'=')
    .';-'        .'-'.        '\\$'        .'=;'        .('['        ^'(')
    .('['        ^'.')        .(' '         '"')        .('!'        ^'+')
   .'_\\ '      .'(\\$'      .';=('.      '\\$= '      ."\ ".(      ' '^'.'
  ).((' ')     '/').').'    .'\\"'.+(    ' '^'[').    (' ' '"')    .(' ' '/'
 ).('['^'/')  .('['^'/').  (' ' ',').(  ' ' ('%')).  '\\".\\"'.(  '['^('(')).
 '\\"'.('['^  '#').'!!--'  .'\\$=.\\"'  .(' '^'[').  (' ' '/').(  ' ' "\&").(
 ' '^"\[").(  ' ' "\"").(  ' ' "\%").(  ' ' "\%").(  '['^(')')).  '\\").\\"'.
 (' '^'[').(  ' ' "\/").(  ' ' "\.").(  ' '^"\[").(  '['^"\/").(  ' ' "\(").(
 ' ' "\%").(  ' '^"\[").(  '['^"\,").(  ' ' "\!").(  ' ' "\,").(  ' ' (',')).
 '\\"\\ '.+(  '['^"\+").(  '['^"\)").(  ' ' "\)").(  ' ' "\.").(  '['^('/')).
 '+_,\\",'.(  ' '^('[')).  ('\\$;!').(  '!'^"\+").(  ' '^"\/").(  ' ' "\!").(
 ' ' "\+").(  ' ' "\%").(  ' '^"\[").(  ' ' "\/").(  ' ' "\.").(  ' ' "\%").(
 ' '^"\[").(  ' ' "\$").(  ' ' "\/").(  '['^"\,").(  ' ' ('.')).  ','.((' ')^
 '[').("\["^  '+').("\ "   '!').("\["^  '(').("\["^  '(').("\ "^  '[').("\ " 
 ')').("\["^  '/').("\ "^  '[').("\ "   '!').("\["^  ')').("\ "   '/').("\["^
 '.').("\ "   '.').("\ "   '$')."\,".(  '!'^('+')).  '\\",_,\\"'  .'!'.("\!"^
 '+').("\!"^  '+').'\\"'.  ('['^',').(  ' ' "\(").(  ' ' "\)").(  ' ' "\,").(
 ' ' ('%')).  '++\\$=" )'  );$:=('.')^  '~';$~='@'   '(';$^=')'^  '[';$/=' ';

Recently I noticed that some parking spots in the city area are reserved for car sharing. There seems to be two car sharing companies operating. Flexicar [1] costs $50 to join, has a $10 per month membership fee (which includes one hour of driving at a value of $12), and costs $12 per hour or $80 per day to drive a car plus $0.15 per Km if you drive more than 100Km in a day. They also have pre-paid plans which bring all the guesswork and complexity of mobile phone bills to car rental. Also they give discounts to members of the City Rewards [2] program which are greater than the membership cost, so anyone who plans to join them should join City Rewards first. To use a car you phone up or use their web site to make a reservation. Then you find the car you reserved at it’s designated location and swipe your card across the windscreen to unlock the doors (presumably it’s an RFID card). The glovebox has the key for the ignition as well as fuel cards for any fuel you use a BP, Shell, and Caltex petrol stations (presumably if you run low on petrol when not near those ones you end up paying). All you pay is the rental rate and any tolls for toll roads you use. When someone doesn’t return the vehicle to it’s designated spot on time there are penalty rates, which may include the cost of a taxi fare for the next person who had booked it. It seems like a really good idea that can save significant amounts of money for people who live in the central areas (the costs of maintaining and insuring a car are significant, as is the depreciation on a new car as an asset). The competitor is Charterdrive [3] which costs $25 to join (less than Flexicar but the same once you consider the discount), the same $10 per hour for 8:30AM to 5:30PM hours, and then cheaper rates for evenings and weekends. $25 for a night (5:30PM to 8:30AM the next morning) is good value if you want to drive home from work and then return the next day (if you work late then you might expect to pay $30 or more for a single taxi ride to get home). The weekend rate of $90 for 5:30 Friday to 8:30 Monday is also quite competitive, I expect that there are many people who only use a car on the weekend who could benefit a lot from this. $90 per weekend for 40 weekends a year (some weekends you would stay home or just use public transport) is $3600, insurance, registration, and basic maintenance of a car that you would want to own would cover most of that. Charterdrive does charge $0.20 per Km though for all journeys (with a discount rate of $0.15 per Km for long journeys on some plans), as opposed to Flexicar only charging $0.15 per Km for distances in excess of 100Km per day. Charterdrive seems to be a newer company and has a far smaller presence. But it’s business model seems a little different and the focus on renting cars for people to drive home means that some people might benefit from being members of both companies. The $0.20 per Km makes Charterdrive more expensive more expensive for most city use, and the discounts offered for Flexicar seem to make it cheaper for use during business hours. Charterdrive states that they have a deal with Red Spot Car Rentals [4]. It is not stated on their web site if you want to use one of their cars and they are all in use, I wonder whether a Red Spot car would be provided for the same price. Flexicar however claims that they aim to have a ratio of cars to members sufficient to make such things unlikely. Maybe it would be prudent to join both organisations so that if one had no vehicles available then you could use the other? In one city car park that I often pass the Flexicar and Charterdrive parking spots are adjacent so there would be no difference in convenience in terms of which one you use. I wonder whether they will continue getting adjacent spots. If many people join both organisations then it would be more effective if they don’t get adjacent spots to get better aggregate coverage. I think that at the moment the main challenge for both companies is to grow the popularity of the car-sharing business. I expect that the real competition for who gets the biggest slice of that business will happen in a few years time. Update: There is another Australian car-share company in operation named GoGet [5], interestingly I discovered their existence when I reviewed the Google advertising on this post… GoGet has a significant presence in Sydney, a small presence in Melbourne, and is only making a start in Queensland. Their hourly rates are significantly lower than the others (as little as $4.40 per hour) but distance rates are as high as $0.35 per Km. One significant benefit is that they have plans for two or three drivers which could allow an entire family to sign up on one account. If you drive less than 20Km in an hour (which would not be uncommon in city driving) then GoGet would be cheapest.

• [1] https://www.flexicar.com.au/


• [2] http://www.thepegasusgroup.com.au/com/cityrewards/index.htm


• [3] http://charterdrive.com.au/


• [4] http://www.redspotrentals.com.au/


• [5] http://www.goget.com.au/

Share This

First of all, congratulations Steve!
Debian Project Leader Election 2008 Results
The winner of the election is Steve McIntyre.

Security and languages
Meanwhile, Steve Kemp confirms my preference (prejudice?) that Debian maintainers and sponsors must have an understanding of the language used for their packages. (I do not maintain or sponsor KDE, Python or Mono packages for this reason - my C++ knowledge is too patchy to do more than a few queries of the apt C++ interface and I wouldn't understand a single line of python or mono source code.)
Andrew Pollock thinks that all C bugs are upstream bugs.
"Any bug in the software packaged is inherently an upstream bug, and the problem of the upstream author" - noting that he also has a good relationship with upstream and feels competent to apply and refit patches. I must say, I feel that this not something I could consider doing myself or recommending to anyone as sponsor.
Steve Kemp is naturally taking the security point of view and I fully agree that understanding the infamous Smashing The Stack For Fun And Profit (the code itself may need a few updates to work but it still explains the issues) is part of the job of any maintainer or sponsor handling a package that contains a setuid or setgid binary.
I'm upstream for some of my Debian packages and one, in particular, has known issues with static buffers which I inherited from the old upstream. Most of those have been removed but some are embedded a little too deeply into the codebase and it will take time to remove them all. (The ones I know about are tagged in the doxygen output of the source code.) My other programs use GLib dynamic string allocation / parsing instead of calling strcpy and friends directly.
I don't think it is fair or reasonable to maintain a package in a state that would require a new upstream release to fix a critical security bug. Equally, not being able to fix such a bug by creating the patch yourself (e.g. when upstream is not contactable) is also, IMHO, sub-optimal. (The security team are busy enough as it is without being required to write the patches as well.) As I've found with one of my own upstream packages, removing or protecting static buffers is not necessarily trivial and just extending the buffer is usually insufficient. Poor code design or code that is simply very old and stale can be hard to update. (Removing one static buffer required a patch/RCS commit changing some 300 lines in 6 source files during the development of one of my packages.) Changing the buffer behaviour can also cause mysterious bugs elsewhere - in the case of the package referred to above, inability to read or write its own data files and likely corruption of existing files. Thankfully, that application is never going to be one that needs setuid or setgid and is already in a much better state than it was in the Etch release so I'm working on fixing the other buffer issues but without the urgency that would otherwise be necessary.
I'm still learning about improving the security implications of my own code - I would certainly not be happy maintaining a package that uses a root process or a daemon that was written in a language that I simply don't understand, no matter how good my relationship with upstream. IMHO, the problem with security bugs is that the person writing the patch often has to understand the language and the package at a fairly deep level if the fix is not to cause bugs elsewhere in the application. Fixing a static buffer by breaking the application isn't good but then neither is leaving a Debian security bug open whilst waiting for upstream to create a suitable patch for your own Debian package. The problem gets worse if the security bug is architecture-specific or the fix causes bugs that only appear on certain architectures. There are some things that matter in Debian that simply do not matter as much upstream - if a security bug lands in that gap, the Debian maintainer must be able to solve the problem in Debian - at least, that is how I see it.

We escorted Sarge to its last home. 3.1r8 is done, thanks to all the people who made it possible. A big thanks goes to James Troup, our ftpmaster of the day doing all the grunt work of getting a new point release out of the door. To bring in a more personal feeling of who makes this all possible, here is a list of people contributing uploads to 3.1r8 (mostly people from our fabulous Security Team):

• Alberto Gonzalez Iniesta
• dann frazier
• Darren Salt
• Devin Carraway
• Florian Weimer
• Gregory Colpart
• Julien Cristau (who is glad that he finally got rid of xfree86)
• Luk Claes
• Martin Pitt
• Michael Koch
• Moritz Muehlenhoff
• Noah Meyerhans
• Patrick Schoenfeld
• Roland Mas
• Russ Allbery
• Sean Finney
• Steffen Joeris
• Thijs Kinkhorst

I would also like to thank dann frazier, Luk Claes, Martin Zobel-Helas and Neil McGovern for helping with the preparation of the point release.

I highly recommend making some time to read the The Australian Open Source Industry & Community Report. Based on a census of the Australian Open Source community conducted at the end of last year, it presents a range statistics about the state of the Open Source community and industry in Australia. The report seems to be aimed at demonstrating to Government and Businesses that Open Source has become a very viable business strategy in Australia and in particular how increased adoption of Open Source would reduce the Australian trade deficit. You don’t need to worry about being put to sleep. The report is relatively casual in tone and easy to read with lots of bright graphs to present the key statistics and findings. Including:

• The Australian Open Source industry generates around AUD$500M in annual revenue. A small proportion of the AUD$54.4B total revenue for the Australian ICT Industry in 2004-2005. Lots of growth potential!
• 70-80% of the industry is based on the traditional development, customisation, support and maintenance business model.
• Most of the individuals making up the Australian Open Source community are working professionals, over half the community are in a relationship and a third of the community have children.

It would be fascinating to see a similar study of the New Zealand industry. I suspect that we would find that Open Source businesses are spread across the country similar to Australia. Obviously our community and financial figures would be smaller in absolute terms but would our proportion of Open Source based businesses be similar? Maybe a good task for the current NZOSS committee would be to round up some of the larger Open Source businesses in New Zealand, along with the Ministry of Economic Development to sponsor a similar study for New Zealand!

For a Debian package creation seminar:

• Debian Policy Reference
• Filesystem Hierarchy Standard
• Debian Reference
• New Maintainers Guide
• RTorrent - the simple example

There's a 10 Downing Street e-petition asking for the National Archive to use ODF and not Microsoft's OOXML as planned. Not sure if we can really stop gov.uk selling our heritage to Microsoft now, but it seems worth the effort to sign it.

While looking at poll about Czech open source for first time, I was surprised that two of my projects got in - phpMyAdmin and Wammu. After looking again at that page I noticed there is a typo in phpMyAdmins name, it was written as phpMinAdmin. Then I looked even more carefully and even URL it is pointing to is something different. In this time I realized that it is something completely different with just very similar name. phpMinAdmin is some minimalistic clone of phpMyAdmin, but why they could not choose a bit more different name? PS: Anyway you can still vote for Wammu in Czech open source :-).

I have mostly shifted my main development language to Ruby, as most of the work I do tends to be pretty well covered with Rails. That's not new, however - What is new is that I feel I have got to the point where I actually have something to share. And it feels very good.
So my next couple of posts (three, actually) will be covering some plugins I've written. They are, of course, just sketched - but they work reliably enough to be deemed as useful by their author ;-)
Today I will start by blogging about RealFK. Of course, I will be copying from its documentation/description - I wrote it as well, so I'm not really plagiarizing my own site. I'm not suing self. You can of course also browse the RealFK SVN tree. References Rails is built upon a "dumb database" concept. Rails assumes the database will not force restrictions upon the user - i.e. that the model validators are all there is. But I disagree ;-) I was raised with PostgreSQL, not with MySQL, and I do believe the database can and should impose sane values - It should impose trust on the data..
So, if you want to create a relation field, properly acting as a foreign key and refering to another table, instead of doing it via the ActiveRecord::ConnectionAdapters::TableDefinition#column (or even ActiveRecord::ConnectionAdapters::TableDefinition#references) methods, declare them with add_refrence:

  def self.up
    create_table :proposals do  t 
      (...)
    end
    create_table :proposal_types do  t 
      (...)
    end
    create_table :proposal_statuses do  t 
      (...)
    end
    add_reference :proposals, :proposal_types
    add_reference :proposals, :proposal_statuses, :null => false, :default => 1
  end

The corresponding fields (proposal_type_id and proposal_status_id, respectively) will be created in proposals, and the RDBMS will impose a Foreign Key constraint. The references can be removed via remove_reference, i.e., for inclusion in down migrations:

  def self.down
    remove_reference :proposals, :proposal_types
    remove_reference :proposals, :proposal_statuses
    drop_table :proposal_statuses
    drop_table :proposal_types
    drop_table :proposals
  end

Of course, in this case the remove_reference call is not really needed - But if you are dropping a table that is referred to from a table that will remain existing, you will have to remove the foreign key constraints (that is, the referring columns). Join (HABTM) tables When you define a simple has_and_belongs_to_many (HABTM) relation in your model, you are expected to create an extra table representing this relation. This is a very simple table (i.e. it has only a row for each of the related table‘s IDs), and it carries foreign key constraints.
Please note that join tables are not supposed to carry any extra columns - If you need to add information to join tables, think twice and better use a has_many :elements, :through => :othermodel declaration, and create the othermodel table manually. To create a HABTM table representing that each person can attend many conferences and each conference can be attended by many people:

  def self.up
    create_table :people do  t 
      (...)
    end
    create_table :conferences do  t 
      (...)
    end
    create_habtm :people, :conferences
  end
  def self.down
    drop_habtm :people, :conferences
    drop_table :people
    drop_table :conferences
  end

The last call will create a conferences_people table (according to Rails' conventions, table names are sorted alphabetically to get the join table‘s name).
Note that in this case, in the down migration, the drop_habtm call must appear before the drop_table calls, as it carries foreign key constraints.

• Words Will Tell
  Andrew Bird on songmaking.
• Says it all really ....
  (applies to all online collaboration tools)
• Talk on disk as the new RAM
• Wii hacking and the Freeloader
  "Since such an important component failed open, it s clear higher assurance development techniques are needed for software protection and crypto."

Using Xfce on your laptop running Debian? The battery plugin is unusable? Don't panic, we're aware of this. Basically, the situation is a mess, for some reasons:

• upstream plugin only supports reading in /proc/acpi and /proc/apm
• /proc/acpi now only exists if CONFIG_ACPI_PROCFS_POWER=y in the current kernel config
• CONFIG_ACPI_PROCFS_POWER is deprecated and may be dropped in 2.6.26
• there's no warranty CONFIG_ACPI_PROCFS_POWER will be set for kernel shipped in Lenny

There is an open bug in Debian and in Xfce where we track the situation. Somebody proposed on the Xfce bug a patch to enable sysfs support on the battery plugin, and we integrated this patch on Debian (starting 0.5.0-3), but the patch is not really good, as it hardcodes too many things, and especially the directory names (it uses AC and BAT* while some people are know to have ACAD). So with the sysfs patch included, the plugin doesn't work at all on some users's config. The next plan is to remove this sysfs patch and revert to procfs, until we know better how everything will be in Lenny. In the meantime, Nick Schermer is hacking on a hal based branch of the battery plugin. I'm currently running it daily, and it works fine. Nearly all the low-level work is let to hal, and the battery plugin only takes care of the display, in Xfce panel. This is nice, but add a dependency on hald for the battery plugin, wich is something some user may not want. At first, I thought it would be better to release Lenny with 0.5.0 battery plugin and only after switch to the hal based one, and add the hald dep, especially since the plugin is still kind of experimental. But seeing the mess it is currently, we may have to switch before, and sooner than we thought. [EDIT]: xfce4-battery-plugin_0.5.0-6 was just ACCEPTED. It contains a fixed sysfs patch which fixes the “hardcode” problem. Thanks to Daniel Gibson!