Andreas Barth: Cleaning up wanna-build
After adding the new triggers to auto-build wheezy-backports and jessie
yesterday, today I cleaned up the remaining bits in wanna-build from lenny:
wanna-build=> delete from packages where distribution ~ 'lenny' ;
DELETE 8250
wanna-build=> delete from distribution_architectures where distribution ~ 'lenny';
DELETE 63
wanna-build=> delete from locks where distribution ~ 'lenny';
DELETE 63
wanna-build=> delete from pkg_history where distribution ~ 'lenny';
DELETE 16504
wanna-build=> delete from distributions where distribution ~ 'lenny';
DELETE 6
wanna-build=> delete from architectures where architecture in ('alpha', 'arm', 'hppa');
DELETE 3
One of my recent innocent tweet about Gerrit vs Github triggered much more
reponses and debate that I expected it to. I realize that it might be worth
explaining a bit what I meant, in a text longer than 140 characters.
I always looked at Github from a distant eye, mainly because I always
disliked their pull-request handling, and saw no value in the social hype it
brings. Why?
One click away isn't one click effort
The pull-request system looks like an incredible easy way to contribute to
any project hosted on Github. You're a click away to send your contribution
to any software. But the problem is that any worthy contribution isn't an
effort of a single click.
Doing any proper and useful contribution to a software is never done right
the first time. There's a dance you will have to play. A slowly rhythmed
back and forth between you and the software maintainer or team. You'll have
to dance it until your contribution is correct and can be merged.
But as a software maintainer, not everybody is going to follow you on this
choregraphy, and you'll end up with pull-request you'll never get finished
unless you wrap things up yourself. So the gain in pull-requests here, isn't
really bigger than a good bug report in most cases.
This is where the social argument of Github isn't anymore. As soon as you're
talking about projects bigger than a color theme for your favorite text
editor, this feature is overrated.
Contribution rework
If you're lucky enough, your contributor will play along and follow you on
this pull-request review process. You'll make suggestions, he will listen
and will modify his pull-request to follow your advice.
At this point, there's two technics he can use to please you.
Technic #1: the Topping
Github's pull-requests invite you to send an entire branch, eclipsing the
fact that it is composed of several commits. The problem is that a lot of
one-click-away contributors do not masterize Git and/or do not make efforts
to build a logical patchset, and nothing warns them that their branch
history is wrong. So they tend to change stuff around, commit, make a
mistake, commit, fix this mistake, commit, etc. This kind of branch is
composed of the whole brain's construction process of your contributor, and
is a real pain to review. To the point I quite often give up.
<figure>
<figcaption>
A typical case: 3 commits to build a 4 lines long file.
</figcaption>
</figure>
Without Github, the old method that all software used, and that many
software still use (e.g. Linux), is to send a patch set over e-mail (or any
other medium like Gerrit). This method has one positive effect, that it
forces the contributor to acknowledge the list of commits he is going to
publish. So, if the contributor he has fixup commits in his history, they
are going to be seen as first class citizen. And nobody is going to want to
see that, neither your contributor, nor the software maintainers. Therefore,
such a system tend to push contributors to write atomic, logical and
self-contained patchset that can be more easily reviewed.
Technic #2: the History Rewriter
This is actually the good way to build a working and logical patchset using
Git. Rewriting history and amending problematic patches using the famous
git rebase --interactive trick.
The problem is that if your contributor does this and then repush the branch
composing your pull-request to Github, you will both lose the previous
review done, each time. There's no history on the different versions of the
branch that has been pushed.
In the old alternative system like e-mail, no information is lost when
reworked patches are resent, obviously. This is far better because it eases
the following of the iterative discussions that the patch triggered.
Of course, it would be possible for Github to enhance this and fix it, but
currently it doesn't handle this use case correctly..
<figure>
It's not a secret for anyone that I've been contributing to OpenStack as a
daily routine for the last 18 months. The more I contribute, the more I like
the contribution workflow and process. It's already
So while testing 
It s actually documented at 
Some weeks ago, I contacted Rosa Mart nez, a tech journalist with some questions regarding what I regarded as 
We ve got all sorts of spiffy changes lined up and another major release! We ve got Hy version 
With wheezy released, the floodgates are opened on a lot of debhelper
changes that have been piling up. Most of these should be pretty minor, but
I released one yesterday that will affect all users of 
The 'longhaul' module may cause instability or even hardware damage
on some systems. Unfortunately, it is now being auto-loaded on all
systems with a compatible CPU (VIA C3 or Cyrix III). See
Congrats to the Debian release team on the
TL;DR: 
A massive marathon has resulted in my lumail mail client working well.
Functionally the application looks little different to the previous C-client, but
it is a lot cleaner, neater, and nicer internally.
The configuration file 
I've been working on TPMs lately. It turns out that they're moderately awful, but what's significantly more awful is basically all the existing documentation. So here's some of what I've learned, presented in the hope that it saves someone else some amount of misery.
Ordinarily, I m a big believer that it is important to keep up to date with what every piece of software which competes with yours is doing, to remain educated on the latest concepts. Sometimes, there are concepts that get added which are definitely worth ripping off. We ve ripped off plenty of the better design choices from Windows or Mac OS, over the years, for use in the Free Desktop.
So, what about Windows 8, the hip new OS on everyone s lips?
Well, here s the thing I ve been using it on and off for a few months now for running legacy apps, and I can t for the life of me find anything worth stealing.
Let s take the key change Windows 8 has apps built with a new design paradigm which definitely isn t called Metro. Metro apps don t really have windows in the traditional sense they re more modeled on full-screen apps from smartphones or tablets than on Windows 1.0 -> 7. Which is fine, really, if you re running Windows 8 on a tablet or touchscreen device. But what if you re not? What about the normal PC user?
As Microsoft themselves ask:
PackagesI quite like the current status of Qt 5 in 
As student application period of Google Summer of Code 2013 is over, it's time to look at proposals we got for 
Quite unsurprisingly the most interesting topic seemed to be interface improvements, though it is quite wide. You can see how other topics were frequent in following chart:
Please note that the numbers are not 100% accurate as some proposals really did not fit into above categories.
Anyway we're just working on evaluation and will finalize it in upcoming days. Of course you will know the results from Google on May 27th.