TL;DR: if you applied for a DebConf 17 travel bursary, and you haven’t accepted it yet, login to the DebConf website and update your status before June 20th or your bursary grant will be gone.

*blows dust off the blog*

As you might be aware, DebConf 17 is coming soon and it’s gonna be the biggest DebConf in Montréal ever.

Of course, what makes DebConf great is the people who come together to work on Debian, share their achievements, and help draft our cunning plans to take over the world. Also cheese. Lots and lots of cheese.

To that end, the DebConf team had initially budgeted US$40,000 for travel grants ($30,000 for contributors, $10,000 for diversity and inclusion grants), allowing the bursaries team to bring people from all around the world who couldn’t have made it to the conference.

Our team of volunteers rated the 188 applications, we’ve made a ranking (technically, two rankings : one on contribution grounds and one on D&I grounds), and we finally sent out a first round of grants last week.

After the first round, the team made a new budget assessment, and thanks to the support of our outstanding sponsors, an extra $15,000 has been allocated for travel stipends during this week’s team meeting, with the blessing of the DPL.

We’ve therefore been able to send a second round of grants today.

Now, if you got a grant, you have two things to do : you need to accept your grant, and you need to update your requested amount. Both of those steps allow us to use our budget more wisely: having grants expire frees money up to get more people to the conference earlier. Having updated amounts gives us a better view of our overall budget. (You can only lower your requested amount, as we can’t inflate our budget)

Our system has sent mails to everyone, but it’s easy enough to let that email slip (or to not receive it for some reason). It takes 30 seconds to look at the status of your request on the DebConf 17 website, and even less to do the few clicks needed for you to accept the grant. Please do so now! OK, it might take a few minutes if your SSO certificate has expired and you have to look up the docs to renew it.

The deadline for the first round of travel grants (which went out last week) is June 20th. The deadline for the second round (which went out today) is June 24th. If somehow you can’t login to the website before the deadline, the bursaries team has an email address you can use.

We want to send out a third round of grants on June 25th, using the money people freed up: our current acceptance ratio is around 40%, and a lot of very strong applications have been deferred. We don’t want them to wait up until July to get a definitive answer, so thanks for helping us!

À bientôt à Montréal !

TL;DR: In this post, I describe how to configure git to use scripts that automatically resolve conflicts on files where they don't matter: log files, that are chronologically ordered, and set files, where only the set of lines matters and not the order.

I use git to version many things, from papers to code to scripts to configuration. For several of these projects, I am the only user, and I mostly use git to synchronize things across machines. Conflicts then become something of a nuisance; while they can be avoided by always pulling before editing, this is not always possible, e.g., when I'm offline, or forget to do this. However, there are files on which conflicts do not matter, and are easy to solve:

• One example are log files, i.e., files that log timestamped events, one per line. For such files, we can reconcile conflicts by merging events, intuitively sorting the lines by timestamp and deleting all conflict markers. I use this for a log of personal notes, but the same should work if you want to version, e.g., your bash history.
• Another example are set files, i.e., files that describe a set, each line being an item, and with irrelevant order between the lines (and no duplicates). One example are vim spellchecking additions, when synchronizing them across machines. For such files, intuitively, we can solve conflicts by discarding duplicate lines and dropping conflicts markers.

I used to solve these conflicts by hand, but this was tedious and error-prone. I then realized that I could use custom merge drivers with git to automate this away. I have been using the setup for some months now without issues.

Set files

Let me start with this case, because it is simpler, and let me present things top-down. We will first add a file .gitattributes to our repository to indicate that a custom merge strategy should be used for some files. For instance:

cd myreporoot/
cat > .gitattributes <<EOF
mysetfile1.txt merge=set
mysetfile2.txt merge=set
EOF

Of course, you should then version this file with git:

git add .gitattributes
git commit -m 'automatic merges' .gitattributes

Now, we have to tell git what we mean by the set merge strategy. This is explained in the section "Defining a custom merge driver" in the gitattributes documentation or the manpage gitattributes(5), but I will summarize it here. Edit your .gitconfig file to register the set merge strategy:

cat >> ~/.gitconfig <<EOF
[merge "set"]
  name = set merger
  driver = ~/bin/git-merge-set %O %A %B %L
EOF

Now we have to create the ~/bin/git-merge-set script. This is fairly easy to do, once you have understood the meaning of the arguments that git passes to the program. Here is for instance my git-merge-set script, which concatenates the files and deletes duplicates (in a stable way, i.e., it preserves the order in the input files). Note that it depends on sponge from moreutils.

You should now be able to commit in your repository, pull conflicting changes as you like, and never hear about the conflicts on the files for which you have defined custom strategies. When pulling, git will just tell you that it is merging the changes, and everything will work fine.

Log files

For log files, it works exactly the same way, replacing "set" by "log" in all steps above, except that you have to define a different merge strategy. The script to write depends on the format of your log entries. Mine have a numerical timestamp, a space, and the line contents, and I use this git-merge-log script. Feel free to adapt it.

I have applied to computer science research and teaching positions in France over the year 2015-2016, and obtained my current associate professor position in Télécom ParisTech. These application processes are public competitive exams, but there is not so much information available about them online, and many of my friends who are applying for 2016-2017 have asked me for a copy of my application files.

I thought that it would be better for this information to be available online, so that it may benefit all candidates equitably. So I have written a description of the applications I did last year, along with all the documentation I have submitted. I am making this a separate page, because I will probably need to update it, even though I will not necessarily make the effort to keep it completely up to date as these contests evolve.

Here is the page: Application to research positions.