It looks like questions about contributing to phpMyAdmin are more and more frequent with upcoming GSoC. The fact that is still time for organizations to apply and it's not yet decided whether we will be accepted or not does not change anything. But before asking, please try to look up existing resources. We have lot of information available on wiki, with entry point being contribution page on website. You should find there all basic information how project works. Should you specifically ask for GSoC, we have an applicant guide, which tells you what to do if you want to apply. After last year experiences, we will be even stricter on previous contributions, because it turned out to be good filter for people who would have problems with contributing during GSoC as well. In case you don't know where to start, there is list of junior jobs which should not be that complicated and then there is of course GSoC ideas list with things primarily targeted on GSoC.

Filed under: English Phpmyadmin 0 comments Flattr this!

For those who are interested in the world of compiz, new development snapshots have been trickling their way into experimental for the past week and are now available for widespread testing. They're being sent to experimental instead of straight to unstable for a few reasons:

• None of us really know how stable / problematic they will be, whether they will build on all arches, or have other RC bugs. So this lets us evaluate the situation and not commit ourselves if we think it's still premature to support them.
• Updating these packages is a major pain and very time consuming, due to how the authors choose to maintain/organize their software. This is really a rant for another day though. Short version is that packages have to be dealt with manually and in a serial manner, and this means they don't all arrive ready to go in one evening's worth of work.
• Since 0.8.x, the upstream authors have moved the locations of some of the repositories, and in some cases rebuilt the repositories from scratch in the process. That meant I had to spend lots of time learning about how to do a few arcane things in git.
• Some of the new packages are using git submodules, which by itself isn't necessarily bad. However, for maintaining debian packages out of git with submodules, this a fairly exotic concept and requires some changes to the typical packaging workflows as well as maybe needing to hack some support into commonly used packaging tools.

So, anyway, the packages are all uploaded now--give them a try!

Another week is over and it's time to spam^W look again at state of translations for phpMyAdmin 3.4. There are no changes to list of complete translations, so we still have 12 translations at 100%:

• Catalan
• Chinese (China)
• Czech
• Dutch
• English (United Kingdom)
• French
• Greek
• Russian
• Slovenian
• Spanish
• Swedish
• Turkish

There are still lot of translations which would need some love:

• German
• Norvegian
• Polish

And I'm really happy to see progress of some exotic languages (at least for me) such as Urdu. You can help make translation to your language better! If your language is missing just let me know (either in comments or by email).

Filed under: English Phpmyadmin 2 comments Flattr this!

Nokia has announced that it is selling off its Qt business. This needed to happen given the change in the company's strategy. Microsoft is a software vendor providing Mobile OS, with Nokia being one of its consumers. For Nokia, to have a tier 1 alliance with Microsoft, it would have been important for the company to show positive gesture. With this move, Microsoft and Nokia will strengthen their partnership. This move will focus on tighter integration in between the 2 company's portfolios. Nokia mentioned in the announcement that it'd further continue Qt core development. I don't see what value that has to bring to the company. It either has to do with the company making some money with whatever IP it acquired in Trolltech, or else, it'd be just a phased wise approach in selling off the Qt business. Also it could be Nokia's Plan B, in case the Micro-Noki team fails to build the ecosystem that it is aspiring for. As for Qt, we'll have to see. Given that it is GPL, we don't have too much to worry (hopefully).

In the software community, people hold strong opinions on the subject of listening to users. Some feel that users are an essential source of information for making successful products, as evidenced in the customer development methodology, and seek to involve users deeply in product development. Others believe that users don t know what they want, invoking the quote attributed to Henry Ford, If I d asked customers what they wanted, they would have said a faster horse . Some say that user needs are unknowable except through the lens of a marketplace, where people choose in aggregate which products suit them best, and customers vote with their wallets (anything else is anecdata ). Regular readers will not be surprised that I believe they are all right, but only in certain contexts. The right strategy for involving users in product decisions will depend on factors related to the product itself, the market, and the product development method being used. One of the most important is the life cycle stage of the product: is it a new and rapidly evolving concept, or a mature commodity, or somewhere in between? Simon Wardley explains this well over on his blog, so I won t rehash his points here, but will add a few of my own. If what we re looking for is inspiration for a new product, it s here that Henry Ford was right: users generally won t hand you a complete product vision on a silver platter. They ll frame their input in terms of what they know, and the choices already available to them. However, this doesn t mean that users don t have a role to play in this instance: watching users can be a great source of inspiration. It s the combination of domain knowledge and passionate imagination which triggers the creative spark. Henry Ford applied his engineer s interests to a problem which was evident all around him. If our goal is to test whether a new product is a good fit for its users, there is no substitute for user feedback. We can guess at whether there is a fit, and our intuition may be good, but users are the ultimate judges, and we don t know if we re right or wrong until users evaluate it. So ask them! By engaging in dialogue with individual users, we can learn unexpected things which will help to refine the idea. If we don t find what they think until our new product is released, we risk making something that no one wants. Why wait until it s too late? It can be challenging to extract useful feedback for a product which doesn t yet exist, but this effort is well worth it to avoid wasting much more effort in software engineering. When our objective is to incrementally improve an existing product, individual anecdotes can mislead us. A given change may be an improvement for one user, but a disaster for another. What we want to know is whether the new version is better for the population as a whole, and in this case, we do well to rely on data. There are pitfalls here as well, of course. We need to choose our questions carefully, and realize that users will often resist any change: not because they re stodgy by nature, but because they have to invest effort in adapting to the change. I think of incremental improvement as a joint investment made between product developers and their users, to improve the whole system of people and technology for the better. By choosing the right tool for the job, we can make better decisions, improve faster, and ultimately solve the right problem for our users.

I've been promoted - my job title will now be 'Software Architect'. This seems to mean I'll be writing documents rather than code - any higher-level, and I'd need Mark Shuttleworth's spacesuit. Is this a good thing? Anyway, I celebrated by opening my last bottle of Debian wine. <spam>Unfortunately, I can't take up my new role until we have hired a replacement. UK-based developers who know Perl and ideally PostgreSQL might want to look at the job description, although I'd recommend sending your CV and covering letter to me directly. I don't get a referral bonus, it's just that I don't like what that agency does with your carefully-crafted application.</spam> I'd like to thank everyone who maintains LaTeX for their assistance in this matter. In other news, I'm studying a couple of Open University courses part-time - one on software development (i.e. UML), and one on interaction design. They're going well so far - I've had a couple of tutorials, and the first part of an assignment came back with good marks. I've been reading the Lean Software Development books by Mary and Tom Poppendieck. They seem to put Agile development into a 'respectable' historical context of similar improvements in manufacturing, which might be useful for persuading project managers.

Terah went to college at Purdue University, and always enjoyed basketball games there. I ve not been much of a sports fan, but have enjoyed watching Purdue games with her on TV. Terah has been wanting to see a game in person for awhile, so a couple of weeks ago, we went. It was a really fun weekend! When we planed the trip, we had no idea that the Purdue-Ohio State game was going to be such a big one. We walked over from the Union Club Hotel where we were staying on the Purdue campus. People were streaming towards Mackey Arena from all directions. Once inside, it was already loud and buzzing people cheering, the band playing. I ve never experienced anything quite so loud. The game started out badly for Purdue; they were down a few points up front. The entire game was a close one, and the crowd sometimes got so loud that nothing else could be heard not even the band or the announcer. When it became clear at the end that Purdue won the game, the people behind me and apparently 12,000 others began screaming at the top of their lungs. My hearing did eventually return to normal. So did my throat, which had gotten rather sore from from cheering myself. This was our first road trip since I got my amateur radio license. I had a lot of fun visiting with people as we drove. I talked to a retired railroad engineer that used to take an amateur radio with him in his locomotive. As he went through a certain town where he had friends he liked to talk with on the radio, he d get their attention by blowing CQ in Morse code with the train s whistle. Some people in Kansas City had us laughing as we passed through. In Missouri, I talked with some farmers and a World War II vet. In Champaign, IL, I visited with a retired Unix systems administrator that had spent decades working with Unix operating systems. Our hotel was connected to the Purdue Memorial Union, a large and historic building. Besides having some ice cream at the Sweet Shop one evening, we also spent a bit of time exploring it. I noticed that the Purdue Amateur Radio Club was having a testing session in there. We walked past once it was underway, and one of the students was not very busy. I introduced myself and asked if we could see their shack. It was neat to see all the equipment some of it quite old in the room that they must have been using for decades. Terah, of course, had ideas for visiting a number of her favorite places while we were there. We visited Arni s and Bruno s, both pizza places. Bruno s happens to be a Swiss pizza place, so much to my surprise, I had Wienerschnitzel there, which was excellent. We ate a (week late) Valentine s dinner at Bistro 501. On our way back, we also chatted with various people on the radio, though not quite as much. We got helpful suggestions for which route to take, and stopped at the excellent Bobby D s Merchant St. BBQ in Emporia, KS for supper. The boys had also enjoyed their weekend with grandparents, but were glad to see us back. They were particularly interested to see a lot of train videos from Youtube with me the next day.

I'm a complete font n00b. How does one install Type1 fonts as part of a Debian package in such a way that:

• The package is policy-compliant
• Ghostscript will find the fonts
• The fonts really live in /usr/share/pmw/psfonts/

PMW, which I'm packaging for Debian, includes Type1 postscript fonts that it absolutely cannot live without; and while it's possible to create a .ps file from pmw that includes those fonts, by default it does not, so it's generally useful to put those fonts somewhere that ghostscript can find them. Only I know squat about how ghostscript finds fonts, and just adding a symlink /usr/share/fonts/type1/gsfonts/pmw -> ../../../pmw/psfonts (as was suggested to me on IRC) does not seem to do the trick. Thanks,

Christian is a figure of Debian, not only because of the tremendous coordination work that he does within the translation project, but also because he s very involved at the social level. He s probably in the top 5 of the persons who attended most often the Debian conference. Christian is a friend (thanks for hosting me so many times when I come to Paris for Debian related events) and I m glad that he accepted to be interviewed. He likes to speak and that shows in the length of his answers but you ll be traveling the world while reading him. My questions are in bold, the rest is by Christian. Who are you? I am a French citizen (which is easy to guess unless you correct my usual mistakes in what follows). I m immensely proud of being married for nearly 26 years with Elizabeth (who deserves a statue from Debian for being so patient with my passion and my dedication to the project). I m also the proud father of 3 wonderful kids , aged 19 to 23. I work as team manager in the Networks and Computers Division of Onera the French Aerospace lab , a public research institute about Aeronautics, Space and Defense. My team provides computer management services for research divisions of Onera, with a specific focus put on individual computing. I entered the world of free software as one of the very first users of Linux in France. Back in the early 1990 s, I happened (though the BBS users communities) to be a friend of several early adopters of Linux and/or BSD386/FreeBSD/NetBSD in France. More specifically, I discovered Linux thanks with my friend Ren Cougnenc (all my free software talks are dedicated to Ren , who passed away in 1996). You re not a programmer, not even a packager. How did you come to Debian? I m definitely not a programmer and I never studied computing (I graduated in Materials Science and worked in that area for a few years after my PhD). However, my daily work always involved computing (I redesigned the creep testing laboratory and its acquisition system all by myself during my thesis research work). An my hobbies often involved playing with home computers, always trying to learn about something new. So, first learning about a new operating system then trying to figure out how to become involved in its development was quite a logical choice. Debian is my distro of choice since it exists. I used Slackware on work machines for a while, but my home server, kheops, first ran Debian 1.1 when I stopped running a BBS on an MS-DOS machine to host a news server. That was back in October 1996. I then happened to be a user, and more specifically a user of genealogy software, also participating very actively in Usenet from this home computer and server, that was running this Debian thing. So, progressively, I joined mailing lists and, being a passionate person, I tried to figure out how I could bring my own little contribution to all this. This is why I became a packager (yes, I am one!) by taking over the geneweb package, which I was using to publish my genealogy research. I applied as DD in January 2001, then got my account in July 2001. My first upload to the Debian archive occurred on August 22nd 2001: that was of course geneweb, which I still maintain. Quite quickly, I became involved in the work on French localization. I have always been a strong supporter of localized software (I even translated a few BBS software back in the early 90 s) as one of the way to bring the power and richness of free software to more users. Localization work lead me to work on the early version of Debian Installer, during those 2003-2005 years where the development of D-I was an incredibly motivating and challenging task, lead by Joey Hess and his inspiring ideas. From user to contributor to leader, I suddenly discovered, around 2004, that I became the coordinator of D-I i18n (internationalization) without even noticing You re the main translation coordinator in Debian. What plans and goals have you set for Debian Wheezy? As always: paint the world in red. Indeed, this is my goal for years. I would like our favorite distro to be able to be used by anyone in the world, whether she speaks English, Northern Sami, Wolof, Uyghur or Secwepemcts n. As a matter of symbol, I use the installer for this. My stance is that one should be able to even install Debian in one s own language. So, for about 7 years, I use D-I as a way to attract new localization contributors. This progress is represented on this page where the world is gradually painted in red as long as the installer supports more languages release after release. The map above tries to illustrate this by painting in red countries when the most spoken language in the country is supported in Debian Installer. However, that map does not give enough reward to many great efforts made to support very different kind of languages. Not only various national languages, but also very different ones: all regional languages of Spain, many of the most spoken languages in India, minority languages such as Uyghur for which an effort is starting, Northern Sami because it is taught in a few schools in Norway, etc., etc. Still, the map gives a good idea of what I would like to see better supported: languages from Africa, several languages in Central Asia. And, as a very very personal goal, I m eagerly waiting for support of Tibetan in Debian Installer, the same way we support its sister language, Dzongkha from Bhutan. For this to happen, we have to make contribution to localization as easy as possible. The very distributed nature of Debian development makes this a challenge, as material to translate (D-I components, debconf screens, native packages, packages descriptions, website, documentation) is very widely spread. A goal, for years, is to set a centralized place where translators could work easily without even knowing about SVN/GIT/BZR or having to report bugs to send their work. The point, however, would be to have this without making compromises on translation quality. So, with peer review, use of thesaurus and translation memory and all such techniques. Tools for this exist: we, for instance, worked with the developers of Pootle to help making it able to cope with the huge amount of material in Debian (think about packages descriptions translations). However, as of now, the glue between such tools and the raw material (that often lies in packages) didn t come. So, currently, translation work in Debian requires a great knowledge of how things are organized, where is the material, how it can be possible to make contribution reach packages, etc. And, as I m technically unable to fulfill the goal of building the infrastructure, I m fulfilling that role of spreading out the knowledge. This is how I can define my coordinator role. Ubuntu uses a web-based tool to make it easy to contribute translations directly in Launchpad. At some point you asked Canonical to make it free software. Launchpad has been freed in the mean time. Have you (re)considered using it? Why not? After all, it more or less fills in the needs I just described. I still don t really figure out how we could have all Debian material gathered in Rosetta/Launchpad .and also how Debian packagers could easily get localized material back from the framework without changing their development processes. I have always tried to stay neutral wrt Ubuntu. As many people now in Debian, I feel like we have reached a good way to achieve our mutual development. When it comes at localization work, the early days where the everything in Rosetta and translates who wants stanza did a lot of harm to several upstream localization projects is, I think, way over. Many people who currently contribute to D-I localization were indeed sent to me by Ubuntu contributors .and by localizing D-I, apt, debconf, package descriptions, etc., they re doing translation work for Ubuntu as well as for Debian. Let s say I m a Debian user and I want to help translate Debian in my language. I can spend 1 hour per week on this activity. What should I do to start? Several language teams use Debian mailing lists to coordinate their work. If you re lucky enough to be a speaker of one of these languages, try joining debian-l10n-<yourlanguage> and follow what s happening there. Don t try to immediately jump in some translation work. First, participate to peer reviews: comment on others translations. Learn about the team s processes, jargon and habits. Then, progressively, start working on a few translations: you may want to start with translations of debconf templates: they are short, often easy to do. That s perfect if you have few time. If no language team exists for your language, try joining debian-i18n and ask about existing effort for your language. I may be able to point you to individuals working on Debian translations (very often along with other free software translation efforts). If I am not, then you have just been named coordinator for your language I may even ask you if you want to work on translating the Debian Installer. What s the biggest problem of Debian? We have no problems, we only have solutions We are maybe facing a growth problem for a few years. Despite the increased welcoming aspects of our processes (Debian Maintainers), Debian is having hard times in growing. The overall number of active contributors is probably stagnating for quite a while. I m still amazed, however, to see how we can cope with that and still be able to release over the years. So, after all, this is maybe not a problem Many people would point communication problems here. I don t. I think that communication inside the Debian project is working fairly well now. Our famous flame wars do of course still happen from time to time, but what large free software project doesn t have flame wars? In many areas, we indeed improved communication very significantly. I want to take as an example the way the release of squeeze has been managed. I think that the release team did, even more this time, a very significant and visible effort to communicate with the entire project. And the release of squeeze has been a great success in that matter. So, there s nearly nothing that frustrates me in Debian. Even when a random developer breaks my beloved 100% completeness of French translations, I m not frustrated for more than 2 minutes. You re known in the Debian community as the organizer of the Cheese & Wine Party during DebConf. Can you tell us what this is about? This is an interesting story about how things build themselves in Debian. It all started in July 2005, before DebConf 5 in Helsinki. Denis Barbier, Nicolas Fran ois and myself agreed to bring at Debconf a few pieces of French cheese as well as 1 or 2 bottles of French wine and share them with some friends. Thus, we settled an informal meeting in the French room where we invited some fellows: from memory, Benjamin Mako Hill, Hannah Wallach, Matt Zimmermann and Moray Allan. All of us fond of smelly cheese, great wine plus some extra p t home-made by Denis in Toulouse. It finally happened that, by word of mouth, a few dozens of other people slowly joined in that French room and turned the whole thing into an improvized party that more or less lasted for the entire night. The tradition was later firmly settled in 2006, first in Debconf 6 in Mexico where I challenged the French DDs to bring as many great cheese as possible, then during the Debian i18n meeting in Extremadura (Sept 2006) where we reached the highest amount of cheese per participant ever. I think that the Creofonte building in Casar de C ceres hasn t fully recovered from it and is still smelling cheese 5 years after. This party later became a real tradition for DebConf, growing over and over each year. I see it as a wonderful way to illustrate the diversity we have in Debian, as well as the mutual enrichment we always felt during DebConfs. My only regret about it is that it became so big over the years that organizing it is always a challenge and I more and more feel pressure to make it successful. However, over the years, I always found incredible help by DebConf participants (including my own son, last year a moment of sharing which we will both remember for years, i think). And, really, in 2010, standing up on a chair, shouting (because the microphone wasn t working) to thank everybody, was the most emotional moment I had at Debconf 10. Is there someone in Debian that you admire for their contributions? So many people. So, just like it happens in many awards ceremonies, I will be very verbose to thank people, sorry in advance for this. The name that comes first is Joey Hess. Joey is someone who has a unique way to perceive what improvements are good for Debian and a very precise and meticulous way to design these improvements. Think about debconf. It is designed for so long now and still reaching its very specific goal. So well designed that it is the entire basis for Joey s other achievement: designing D-I. Moreover, I not only admire Joey for his technical work, but also for his interaction with others. He is not he loudest person around, he doesn t have to .just giving his point in discussion and, guess what? Most of the time, he s right. Someone I would like to name here, also, is Colin Watson. Colin is also someone I worked with for years (the D-I effect, again ) and, here again, the very clever way he works on technical improvements as well as his very friendly way to interact with others just make it. And, how about you, Rapha l? I m really admirative of the way you work on promoting technical work on Debian. Your natural ability to explain things (as good in English as it is in French) and your motivation to share your knowledge are a great benefit for the project. Not to mention the technical achievements you made with Guillem on dpkg of course! Another person I d like to name here is Steve Langasek. We both maintain samba packages for years and collaboration with him has always been a pleasure. Just like Colin, Steve is IMHO a model to follow when it comes at people who work for Canonical while continuing their involvment in Debian. And, indeed, Steve is so patient with my mistakes and stupid questions in samba packaging that he deserves a statue. We re now reaching the end of the year where Stefano Zacchiroli was the Debian Project Leader. And, no offense intended to people who were DPL before him (all of them being people I consider to be friends of mine), I think he did the best term ever. Zack is wonderful in sharing his enthusiasm about Debian and has a unique way to do it. Up to the very end of his term, he has always been working on various aspects of the project and my only hope is that he ll run again (however, I would very well understand that he wants to go back to his hacking activities!). Hat off, Zack!I again have several other people to name in this Bubulle hall of Fame : Don Armstrong, for his constant work on improving Debian BTS, Margarita Manterola as one of the best successes of Debian Women (and the most geeky honeymoon ever), Denis Barbier and Nicolas Fran ois because i18n need really skilled people, Cyril Brulebois and Julien Cristau who kept X.org packaging alive in lenny and squeeze, Otavio Salvador who never gave up on D-I even when we were so few to care about it. I would like to make a special mention for Frans Pop. His loss in 2010 has been a shock for many of us, and particularly me. Frans and I had a similar history in Debian, both mostly working on so-called non technical duties. Frans has been the best release manager for D-I (no offense intended, at all, to Joey or Otavio .I know that both of them share this feeling with me). His very high involvment in his work and the very meticulous way he was doing it lead to great achievements in the installer. The Installation Guide work was also a model and indeed a great example of non technical work that requires as many skills as more classical technical work. So, and even though he was sometimes so picky and, I have to admit, annoying, that explains why I m still feeling sad and, in some way, guilty about Frans loss. One of my goals for wheezy is indeed to complete some things Frans left unachieved. I just found one in bug #564441: I will make this work reach the archive, benefit our users and I know that Frans would have liked that.

---

Thank you to Christian for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

7 comments Liked this article? Click here. My blog is Flattr-enabled.

Well not really. The simple reason is that it does not make sense without further integration with other services. However if you want to deploy such solution, you can now base on example script, I've just pushed to our git repository. It is definitely meant only as example, major reason being storing MySQL user names and passwords in clear text in the PHP script.

Filed under: English Phpmyadmin 0 comments Flattr this!

I'll collect here links to the various linux-2.6 distribution trees based on the longterm release 2.6.32. I won't go into details of bigger external patches (grsec, openvz, rt, xen, ..), which in consequence also aligned themselves on 2.6.32. Important bug fixes usually are connected to some bug report, which may be publicly viewable. So from the patch and changelog entry one can usually assume if a certain patch satisfies the stable criteria and forward it for 2.6.32 longterm inclusion (+ other branches where it might apply). If the patch applies and compiles fine with the Debian tree one can assume that the patch will be fine for upstream 2.6.32 as Debian with small exceptions mostly follows the longterm release: 2.6.32 branch of Debian linux-2.6 (Comment: This is currently only a svn mirror but this bug is worked on for next release). The canonical 2.6.32 linux-2.6 longterm repository is of course on kernel.org maintained by gregkh. Opensuse publishes it's kernel-source on gitorious including all branches and the especially interesting SLE11-SP1 2.6.32 branch. Fedora was following till late Autumn 2.6.32 and the F12 branch has the relevant patches. Ubuntu released 10.04 with 2.6.32 as in a collaborative decision they also based their drm on 2.6.33 (same story as in Debian, thus particularly relevant for us). Oracle had a 2.6.32 that was maintained until Sept 2010 or such. It is already bad that kernel source in Red Hat doesn't really follow upstream 2.6.32 longterm release itself. For 2.6.18 of course no such option existed, but for 2.6.32 this policy already shows a certain snobbery. Red Hat 6.0 Beta at least shipped kernel-2.6.32-37.el6.src.rpm with broken out patches - since then no patch series or git tree to be seen from RH. This strange move got since picked by lwn - RH "obfuscated" kernel source.

Following results of theme survey, I've changed default theme of phpMyAdmin to pmahomme: I'm sure this new attractive look will improve user experience of upcoming 3.4 release. You can expect beta release with new theme soon and then we will hopefully smoothly continue through one (or more) release candidates to final release. While making this theme default one, we've also offered team membership to Mike Homm and I'm quite confident this will be valuable addition to the team. Mike, welcome on board!

Filed under: English Phpmyadmin 0 comments Flattr this!

I spend too much time writing Emacs Lisp code these days. Unfortunately, the more I do the more I find new useful tools to improve my work-flow and save time for doing more Lisp. D'oh. I did not work on any big thing these last weeks, so I'm thinking it's a good time to talk about the various code and patches I sent to multiple Emacs packages. el-get el-get, a fabulous tool that installs and handles all the external Emacs packages I use. A friendly war started on the development list about autoloads handling. The discussion was overall pointless, since we had a very hard time to communicate our ideas, and we did not understand each others several times. In the end, el-get now supports autoload correctly and do not load automatically all your packages, improving the startup time, and using the Emacs way to do things. Which is always better, obviously. git-commit-mode

I've started to use git-commit-mode some times ago. I usually use git-commit with the -v option to see what I'm committing. I though it would be useful to color the diff with diff-mode, so I wrote a patch just to do that, which was merged today by Florian. magit

Some weeks ago, I decided to give a try to magit, and loved it. I am not always using it, but for basic operations it is very useful. But I really soon found some things I did not like and therefore send patches to enhance it. First, I've added a patch to honor status.showUntrackedFiles which I use in my home directory. In the mean time, I've also added a patch to allow adding an arbitrary file. Yesterday, I sent another pull request, not closed for now, which adds the possibility to visit files in another window from a diff file, and the support for add-change-log-entry directly from the displayed diff. Useful for these old projects still using ChangeLog files but accessible through git (hi Emacs & Gnus!). Gnus

Nothing remarkable, but I write a couple of fixes and enhancements to the Sieve manage mode, to the Gravatar code and cleaned-up some very very old code. Also added the possibility to set list-identifier as a group parameter. Org-mode

I spent most of my time working on my jd/agenda-format branch, which is soon to be merged. I've also just got developer access to the Org-mode patch work and repository, so I'll be able to break things even more! ;-) ERC

I fixed the bug that annoyed me for a long time. Now erc-track does not reset the last channel status on window visibility changes not made by the user.

Another week is over and it's time to look again at state of translations for phpMyAdmin 3.4. Compared to last week, there one three translations at 100%, so we now have 12 translations at 100%:

• Catalan
• Chinese (China)
• Czech
• Dutch
• English (United Kingdom)
• French
• Greek
• Russian
• Slovenian
• Spanish
• Swedish
• Turkish

But there are still lot of translations which would need some love:

• German
• Norvegian
• Polish

You can help make translation to your language better!

Filed under: English Phpmyadmin 0 comments Flattr this!

The phpMyAdmin survey for new theme is over and it's time to publish results. Today I will show only basic summary, I will dig deeper into the data later. The first question for default theme has quite clear winner: As the results are quite persuating, this gives no space to discuss. Next question was about inclusion of additional theme in standard download kit: While two themes still have big majority, people are not that convinced about it. The last question of the survey was which theme should be included as additional in the download kit: I think this is most interesting result - while in question about default theme Graphite theme was clearly the second one, in this question people have indicated that Original theme should stay in the download kit. I would like to thank to all 228 people who have participated (the number is low because the survey required email confirmation, but I still think it is better way than thousands of votes which are easily scriptable).

Filed under: English Phpmyadmin 0 comments Flattr this!

Today, you have very last chance to influence selection of new default theme in phpMyAdmin 3.4. You can choose from five themes (all of them are listed on our wiki). Every opinion counts, so please visit our survey and choose the one you like most: http://survey.phpmyadmin.net/index.php?sid=72977 Besides the Original and Darkblue_orange themes, there are following to choose: Toba: Graphite: pmahomme:

Filed under: English Phpmyadmin 0 comments Flattr this!

Everybody hates Xperia When I first got Sony Ericsson Xperia X10 it was running on Android Donut (1.6), my frustrations followed soon after mostly because it was greatly lagging with release of Android 2.1. Finally official 2.1 was released, but troubles didn t stop there, because everybody was waiting for multi-touch support I could go on like this for a very long time. However, to sum it up Sony has no plans of updating X10 anymore, they are releasing brand new phone (Arc) and they are hoping people will pay money to get it after X10 horrors. Even tho 2.1 isn t that old, (31.4% of overall Android users is using it on it), Sony changed its UI to make it look better, but all they actually did is make it look pretty bad + made it abnormally slow. Xperia ROMs From hardware aspect, it s a pretty awesome phone, but from software aspect it waste of nerves. It s obvious that Sony needs to hire more Linux people, because as it seems they have no idea what they are doing. There are of course, 2.2 Froyo and 2.3 Gingerbread straight from Google ROMs, but to be honest phone is only half usable with those. The feeling I get when using these is plain awkward. All these ROMs are stuck on 2.6.29, since as it seems Sony did a very good job protecting its bootloader, what I suggest is to use these for strictly development purposes, and have them dual boot with your working 2.1 2.2.1 Froyo (beta)
http://forum.xda-developers.com/showthread.php?t=917956 Gingerbread 2.3.1 (alpha)
http://forum.xda-developers.com/showthread.php?t=931934 So what is the best ROM? Out of all the ones I tried (and I tried many) it s definitely: kX10 Custom 2.1 SE ROM R2B001
http://forum.xda-developers.com/showthread.php?t=913610 My main argument on what this is the best ROM is because, everything is working, and it s working fast. Author stripped it to the minimum, and what I definitely suggest is that you go with the R2B001 Lite because the Full version comes with too much apps. with it, kinda making this great ROM feel bit bloated. I made a video for you to experience its speed: <iframe allowfullscreen="allowfullscreen" frameborder="0" height="390" src="http://www.youtube.com/embed/8xe0hUx2k28?rel=0" title="YouTube video player" width="480"></iframe> Modifications: Surprisingly I m getting much lower score Quadrant score, but also getting a much higher Linpack score: benchmark results of hacked Stock SE 2.1 ROM (2.0.2.A.0.24 root + JIT) Even though, the phone s much much faster. A couple of screenshots, including Linpack/Quadrant benchmark results. Nexus S This is how I m planning to live my remaining days on this phone, if it wasn t for this ROM, I would ve crashed my X10 long time ago. In meantime I m eagerly waiting to put my hands on Nexus S, whose official release we re still waiting for in Europe Google, please hurry up

I was going to make this a comment against Ritesh Raj Sarraf's post about patents and pharmaceuticals but the comment got way too long.

The basic problem is that patents on pharmaceuticals cannot be directly compared to patents on software and the explanation gets a bit involved. It's worse than apples and oranges, it's more like comparing an algorithm to a piece of DNA.

Patented pharmaceuticals must declare the precise chemical formula of the molecule (and a whole lot else besides) before the molecule can be brought to market but the company holding the patent is legally prevented from protecting themselves against slightly different molecules which are blatantly based on the protected molecule. All modification results in a new patentable product, legally separated from the original.

Therefore, the first company to patent a molecule from a new class is instantly joined in the field by other companies who are (obviously) watching the research news channels very carefully. (In their shoes, you would do the same or you go bust.) These companies simply add a flourine ion or change a hydrogen to a hydroxl group or any other number of minor, apparently inconsequential, changes. Changes which, in software, would be deemed a derivative work and would be roughly equivalent to changing a single local variable from a 16bit integer to a 32bit integer in a single function in a single file in the entire codebase. i.e. a trivial bug fix or even a typo.

A molecule with a couple of hundred atoms can have a change affecting one atom and be a completely new patentable item without any risk of the other company being sued for patent infringement, plagiarism, copyright violation (there is no copyright) or any other barrier. It's common to find that molecule foo is joined on the market by a desoxyfoo and a flourofoo etc. with a chlorofoo just around the corner, within months of the class-leader being launched. It can't be compared to software - effectively, every new release gets a new patent which covers the entirety of everything contained in that release, even if 99.999999999% of it is precisely the same as is covered under other several other patents held by extremely litigious competitors.

Modification is simply not prohibited - copying without making any changes whatsoever to the active molecule is prohibited. Changes to the inactive ingredients will be prosecuted - changes to the active ingredient will not. Comparing this with software is likely to drive you insane.

For example, the mere process of packaging an upstream release for a distribution would be patent infringement in pharmaceutical terms - UNLESS you deliberately patch the original source to make an utterly trivial and apparently pointless change. At that point, the upstream completely disown your entire release and you would have to fix every bug yourself - without the original upstream even telling you whether they fixed the same bug themselves, because they aren't ABLE to modify the upstream code without starting a whole new project and they won't tell you why or how they changed things. There is no such thing as an alpha-release of a molecule. Every release is final and no subsequent modification is possible - unless it only affects the inactive ingredients, e.g. by adding a slow release coating. These changes can affect the way that the molecule acts on the test subject / patient but must not change the active ingredient itself in any identifiable way. So the upstream can make a new wrapper (new packaging) but nobody else is allowed to do so until the patent expires. Once the patent expires, every one and their dog is allowed to make identical copies of the active ingredient in their own inactive packaging and these are called generics. Generics still need testing to ensure that the active ingredient truly is the same and that the generic behaves in the same way as the original but this process is cheaper than making a change to the active molecule.

A changed active molecule is an entirely new substance, it gets a new patent and it needs to go through largely the same amount of testing as the patented original but the new company still gets a head start on what the molecule is likely to do and what side-effects (by now noticeable with the class-leader product which is in large scale trials or even on the market) would be harmful to the future usefulness of their new, derivative, molecule. The new company simply jumps onto the bandwagon shouting "I want a piece of that action!" and there is absolutely nothing the original company can do about it, except try to show that their original molecule is better than the new competitors and to try and build a substantial market share before everyone switches to the new derivative. (Prescribers are human and tend therefore to be lazy, so unless there's a reason to change, the class leader will still have substantial share even after several derivatives exist.)

It's an arms race - each company tries to create as many of these potential "me-too" variants as possible in-house, put as many as can be (financially) supported through trials, keep pursuing those which don't have prohibitive side-effects / problems in tests and hope that, at the end, one of their versions will actually turn out to have better effectiveness or fewer side-effects. If not, they just have to market one as "as-effective-and-no-more-harmful-but-CHEAPER-than" the class leader. The majority of "me-too" molecules come under this category - even if the company concerned would try to point to infinitesimal differences in trial data to pretend otherwise. All this with the knowledge that the very hour that the patent expires, a dozen generic manufacturers will flood the market with copies which do not need to recover the massive costs of the original research and are therefore massively cheaper.

How much cheaper? patented molecules may cost 30 for 28 doses on Monday and one generic may cost 3p for 500, another may cost 40p for 10,000 on Tuesday, the day after the patent expiry. Generic houses only need to cover the actual costs of manufacture, not the costs of the original patent etc. and by the time the patent expires, the efforts of the patent holder to generate market share mean that economies of scale become evident. The absolute cheapest isn't necessarily the one who gets the contract either, these things all have expiry dates and all 10,000 have to be sold / supplied from a single location within that date to actually deliver the full savings. So then you get satellite generics who buy in quantities of a few million and pack down into 56 or less so that the total purchased quantity can sit on many shelves instead of just one. It's the same tablet in the end, with the same markings too. All that differs is the marking on the foil and the colour of the cardboard. (Oh and the same foil and colour cardboard can contain tablets with different markings from different manufacturers from one batch to the next, all within the branding of the same repackaging company.)

The original patent-holding company also has an interest in generating their own "me-too" derivatives, sometimes marketed under the name of a company which turns out to be solely owned by the parent of the original company. It can get horribly recursive.
Sometimes, the derivative from the sibling company hits the market before the "true" competitor from a different company - simply because all companies try to have many molecules in development at any one time (because most changed molecules fail in testing) and sometimes they get lucky and come up with two v.similar molecules and have to do something to justify the cost of developing both. That can turn out to be a poisoned chalice rather than two golden geese.

Sometimes, the company fails to get enough variants through testing and the company then gets bought out by a rival - who then gains their research and continues experimenting with other derivative molecules based on the ones already tested and dismissed. The limiting factor is the money.

At this point, I must now declare my cards. I used to be a pharmacist and although I am still entitled to call myself the holder of a Batchelor of Sciences degree in Pharmaceutical Sciences I am most definitely no longer a pharmacist. I therefore defer to my still-registered colleagues in case I've messed up any of the detail here. The above cannot be declared as the opinion of a pharmacist. I am an ex-pharmacist who voluntarily chose to resign his registration to take up full time work as a software developer rather than pay the exorbitant costs of maintaining such registration and all the "proof-of-competency" requirements which such registration requires.

Finally, before you ask, I am very happy to be an ex-pharmacist - my erstwhile colleagues have my ongoing sympathy but no matter how much some of them may beg, they all know that I will not be rejoining them on that side of the dispensary bench if I've got any choice in the matter.

Software is just better. It's all just recycled electrons.

I have been packaging for Debian for a few years now. My first serious package was Wt back in 2007, but I had been backporting for Ubuntu for at least 2 years already, which means I have been doing .deb packaging for about 5 years (!). Last week I decided it was about time stop nagging my sponsors (Vincent Bernat, Thomas Girard and Sune Vuorela) every time I wanted to update the packages I maintain (witty, ace and libmsn), and I finally started the Debian New Maintainer process. The main reason I had not applied for Debian Maintainer yet was it requires some bureaucracy and, well, I d rather spend my time coding or packaging than doing paperwork I sent my Declaration of Intent and soon after, Thomas and Vincent replied and supported my application with very very nice and kind words. Thank you, guys! I m flattered! Had I known I would be buttered up so much, I would have certainly applied a long time ago! But you know what is the best part of this? It shows how open source projects take advantage of all the tools and communications channels we have (IRC, mailing lists, sprints, conferences, etc), and make distributed development work very well: here we have a 900-developers project in which two French guys are praising an Spanish guy they have never, ever met face-to-face (only e-mail, occasional IRC, and the most important of all: code review). Meritocracy at its full extent. Have you ever seen that in a traditional 100,000 workers company with hundreds of developers working in a single project?

...For the cases where, yes, you actually do want it. For the impatient assuming you're in a clean checkout on the tip of your current branch:

git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

you can then double check that everything is as you expect with git diff ref-to-be-merged, which should be empty. The longer story It's noted from time to time that git does not have a -s theirs option to complement the -s ours strategy when merging (or, it did, but it was removed long ago, see below). For those not savvy the idea with git merge -s ours is to pretend as though a merge from some other branch has occurred, though the result remains the current branch's contents, unchanged. This is a neat trick that can be used to show that all changes in some branch have been superceded by the current branch, which can help ease merges further down the line as parallel devlopment continues. However, there is no corresponding -s theirs option, which would conversely say that "everything developed up to here is superceded by this other branch". This feature was discussed and discarded by one of the git authors, who instead advised a developer to throw away the previous work and start on a fresh branch:

One big problem "-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs". Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you cannot offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all.

In what would probably qualify as "most cases", he's right, but sometimes you do want to do this, and not because you have "crap" in your history, but perhaps because you want to change the baseline for development in a public repository where rebasing should be avoided. In debian, for example, it's pretty common for maintainers who use git-buildpackage to build debian packages from git to have two branches: an "upstream" branch and a "debianized" branch. The upstream branch will follow the changes from the upstream project (either by importing tarballs, or by pulling directly from the project's git repo if they also use git), while the debianized branch contains all the packaging related changes as well as any debian-specific changes to the code. In this context, if the upstream project uses git and rebases their history (out of your control), or if they shift development to a different branch, you might want to have a way to merge with their latest changes without rebasing/abandoning your current debian branch. Hence, a "theirs" merge. The author is totally right that the upstream project may be less interested in pulling from such a repository (since they would drag in the entire previous history), and if that's a problem you might need to splinter off the old branch and start a fresh branch instead. But at least for the projects with which I work, I find that it's more likely that pulling is pretty much one way upstream to debian, and that the patches flow back to the upstream project by way of bug trackers, git format-patch sendmail, or quilt patches sitting in the patch-tracker. And if it becomes a problem later you're no worse off, you can still split off a new branch or take some other action. So anyway, I asked Teh Internetz and found a few hits in the right direction, such as this guy at stack overflow, or this guy here. But from an aesthetic point of view I thought their solutions still left some room for improvement--they were both more complicated, involved setting up temporary branches, and I don't know, just weren't pretty on the eyes. So, ending where I started, this is the relatively clean and easy to follow 3 lines I conjured up, which I will give to teh internetz for posterity.

git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

Alternatively, if you want to keep the local upstream branches fast-forwardable, a potential compromise is to work with the understanding that for sid/unstable, the upstream branch can from time to time be reset/rebased (based on events that are ultimately out of your control on the upstream project's side). This isn't a big deal and working with that assumption means that it's easy to keep the local upstream branch in a state where it only takes fast-forward updates. However, on the debian branch your less interested in the clean upstream development, and instead want to keep a sane history of the debianization work, so on this branch you still do something like a merge -s theirs (though in this case, you probably want to amend the previous version's ./debian dir back in post-merge). So applying the same approach as above with the slight modification, in practice (assuming you're on the clean tip of the debian unstable branch, that'd be):

git branch -m upstream-unstable upstream-unstable-save
git branch upstream-unstable upstream-remote/master
git merge -s ours upstream-unstable
git diff ref-to-be-merged   git apply -R --index --exclude="debian/*"
git commit -F .git/COMMIT_EDITMSG --amend

PS In spirit, this is a similar approach to what's done by the XSF team, though I would argue that with what I'm describing both the approach and the resulting history are a bit cleaner and easier to follow. Also, thanks to ron, mrvn, jcristau, and nthykier on #debian-devel for some quick reviewing of this.