Please, pretty please, do not group patches by files, but by topic !

I'm currently working on putting back vegastrike into shape, bringing slightly more recent code (only three years after the last sourceful upload). And I'm fighting with patches (a good dozen), trying to see what does not apply anymore and what still does, why some patch was written in the first place... I have two requests to the community about that (and, please, do flame me if you think differently ;-)...):

• Please do not group patches by file, but by topic: if a patch modifies the name of a save directory, let it be the only patch to do that, even if it modifies files touched by other patches ! It is very annoying to have to go through the patches trying to see which hunk of which patch does what
• As an extension of the first request, please document why patches are there in the first place: a small explanation is very helpful to determine if one needs to fight to refresh the patch and understand it, or if this is a minor, long-gone problem... Of course, you can only give meaningful description if you group the patches by topic.

Great thanks to all patch writers that think about the ones that could possibly follow them !

mk-build-deps: create a dummy package depending on a package's build-deps

When I work on a package, I often find that I want to have build-deps installed in a way that I remember why I did install them in the first place. apt-get build-dep is not a proper solution for me for two reasons:

• It marks the packages as automatically installed (at least, last time I checked, it did), which does not play nice with aptitude, who wants to remove them immediately. Marking them manually installed would not be a solution either (since I would not remember why I did install them).
• It does not work for package whose build-deps changed since the last upload (or that were never uploaded).

As I'm starting to work on vegastrike, who's in great need of tender care, I though time had to find a more decent solution. The answer is mk-build-deps, a small Perl script that takes a control file or a package name and uses equivs to create a dummy package depending on its build-deps. Pretty useful (for me at least). Maybe it would be worth including in the devscipts package ?

OOXML: Microsoft did win...

Bad news for the OpenSource/FreeSoftware community (or whatever you would wish to call it): ISO has just accepted Microsoft's Office Open XML file formats (see the suble alteration compared to a well known concurrent). Great. Even worse for me, it is apparently thanks to the French organization AFNOR. Fantastic. Now, we have two XML "office open document" formats accepted by ISO. That sounds so amazingly stupid that it's hard to believe... Just for information, the OpenDocument format, (the one from OpenOffice) has been accepted by ISO hardly more than a year ago !