I hereby pledge, that for every mail I send into a thread on the private Debian list with more than 10 mails, I will fix a release critical bug in a foreign package.

Recently, I've learned about git remote helpers feature in Git, which allows to transparently use Git with other version control systems. As Weblate currently supports only Git, it was quite obvious to give this approach a try. After some testing, it actually worked just fine - everything works as expected and you can use Weblate with Mercurial or Bazaar with these helpers. Of course there might be some rough edges, but all standard things I've tried worked just fine. This is now also covered in Weblate's FAQ, which includes basic instructions on how to setup this.

Filed under: English Weblatee 0 comments Flattr this!

These Open Source Days were kind of a mixed experience. The social part Things started off quite nicely; the speaker dinner was very pleasant and the people at my table interesting to talk with. The way back to the hotel and breakfast on Saturday were even more interesting; talking with Amelia Andersdotter, a member of the European Parliament for the Swedish Pirate Party, about anti-trust measures, privacy protection, lobbyists, and creating the right incentives for companies to actually protect user data was fun and engaging. My own claim to fame is that I told her that while Microsoft is willing to sign UEFI payloads for x86, they refuse to do so for ARM which she didn't know. From my understanding, their interpretation is that any anti-trust rulings apply to PCs only, and not general computing devices like tablets. It will be interesting to see how that plays out in the long run, especially once ARM processors start appearing in laptops and desktops as main CPUs where Microsoft clearly still has a near monopoly. It was fascinating to discuss all those issues with someone who's actively involved with legislation, mainly because her style of talking was markedly different from what I am used to. One point which she stressed repeatedly is that the most important skill within the context of political work in the EU is to be able to track down, read, and then reference all the content that's being produced in Brussels and Strasbourg. Maybe that tidbit is useful to people who want to try themselves at political activism. She nicely, and maybe unknowingly, emphasized that point by always referring to specific papers, directives, and studies after making any point. Statement of opinion, reference to supporting document. Statement of opinion, reference to supporting document. Statement of opinion, reference to supporting document. Rinse, repeat. It's no secret that I'm continuously disappointed by the political process in general and politicians in particular. Yet, I have to say that this encounter had a lasting and positive impression on me. Amelia has an incredible amount of energy and genuinely cares about the issues which too many other politicians ignore completely. It's good to know someone like this is on our side. If you're Swedish, please inform yourself about her and consider voting in her favour. Other than that, I met several other people, new and old. This year's OSD felt a lot more relaxed and there were more informal and spontaneous conversations going on in hallways and at tables. Even though I failed to have any intense discussion of Mercurial vs git this year, all those conversation were still really interesting. The "workshop" I already knew that the room assignment for my workshop on Saturday afternoon would be a last-minute thing. What I didn't expect was that the final confirmation by Copenhagen Business School would be given on Friday evening. Mixed with a very cumbersome process to update the slides of the CBS-owned and -operated information beamer in the lobby, this resulted in the official schedule showing my room as "Workshop" instead of "SP 214". The official schedule repeatedly stated that people had to pre-register for the workshop which was a left-over from last year where they actually had to plan the amount of hardware kits needed; the registration itself was was very well hidden behind a rather generic link you saw exactly once after purchasing your ticket. Add to this that my room was literally in the farthest corner of the building and on the top floor and things start to turn sour real quick. All other rooms were either close to the main entrance or on the ground floor. Helpers at the front desk had a lot of people asking where my room was and gave out directions, yet... ...the grand total of six people who arrived were all telling me how they couldn't find the room and almost gave up on finding it. As more people asked for directions than turned up at the workshop, this means that even with directions, the room was really hard to find. Myself, it took me two attempts to find the room after which I was led there by one of the helpers who wasn't completely sure we were going in the right direction, himself. Still, I managed to get everyone who had a laptop and access to a UNIX-based system set up with working mr and vcsh repositories they can work from as well as a demo git-annex repository to play with. Sadly, not everyone had a laptop, or access to UNIX, or the tools installed, or even an idea where to install them from, even though I had noted these "requirements" in the description. Next time I do this workshop, I will need to make sure to include information on what distributions have the relevant packages and how to find and install the software on Max OS X in the workshop description. Feedback from the very few people who actually managed to find me was very good and one of the attendants asked if I would be willing to hold the workshop again at another conference in Denmark. I am still awaiting details on this, but I would obviously enjoy having the chance to reach more people. At least I fared better than the guys who did the workshop on "Binary exploitation 101" in yet another room. Two guys held a workshop with a total attendance of... one... I know the organizers of OSD were really unhappy with how this turned out and I believe them when they say that something like this will never happen again. It's the second year that this team is running the conference, running conferences is an incredible amount of work, and things were smoother this year than last year. Iterate and improve, etc. The talk Saturday evening, Alex offered me the chance to hold a reparation talk on Sunday morning to compensate for the botched workshop. Said talk was scheduled for the first slot and not really announced (but the schedule on both www and the beamer was changed over night). Additionally, this was merely an updated and extended version of the talk which I already held at OSD 2012 so at least part of the visitors knew most of what I had to say, already. To be honest I didn't expect too much, but more than twenty people turned up which is a very decent turnout, all things considered. Same as with the workshop, feedback was extremely positive and I was told afterwards by Bryan that several people mentioned my talk as one of the highlights, or even the highlight, of OSD when he was talking to them. To make things even better this talk has, finally, been videotaped; I will update this blog with a link as soon as the video is online.

Review: Commitment Hour, by James Alan Gardner

Series:	League of Peoples #2
Publisher:	Eos
Copyright:	April 1998
ISBN:	0-380-79827-1
Format:	Mass market
Pages:	343

This is the second book in Gardner's League of Peoples universe, following Expendable, but it is largely unrelated to that novel apart from taking place in the same universe. Expendable follows the portion of humanity that has left Earth and embraced the universe and the advanced technology of the League. Committment Hour is set on Earth, in one of the remaining low-tech settlements that have become a backwater of humanity. Earth is governed by the Spark Lords, who appear to be a sort of scientific artistocracy empowered by the League of Peoples (Gardner gets into this more in later books in the series), but the community in this book is largely left alone. The protagonist of Committment Hour is Fullin, a resident of Tober Cove. The Tober Cove community has a very unusual interaction with gender. Every year, all inhabitants under the age of twenty (starting at the age of two) are taken away by what are viewed locally as gods. When they return, they have the opposite gender. They live their childhoods alternating gender every year, including a mandatory pregnancy (created on one of those trips by the gods) and childbirth. Then, at the age of twenty, rather than being gender-swapped like the other children, they choose the gender that they'll live with for the rest of their life. Fullin is (at least at the start of this book) currently male, but as the book opens on the eve of the day of his final gender committment, he's still undecided on what gender he'll choose. A review of this sort of book immediately requires a significant caveat: this story is all about social constructions of gender and about the implications of one specific transgender scenario. As a cisgender man who fits comfortably within society's normal gender construction, I'm not going to do the best job of judging how well it deals with those issues. It was on the long list for the Tiptree Award, which is a fairly good sign that it does okay, and a quick Internet search didn't uncover any significant dislike, but it's quite possible that I would miss places where it fell short. That said, I found Gardner's presentation of gender fascinating, in large part because Committment Hour is told from deeply inside Fullin's perspective and Gardner treats the Tober Cove gender swapping mostly as the unremarked normal. Fullin and the other inhabitants are quite aware that gender doesn't work for them the way that it does for everyone else, but they consider their gender process entirely sensible and can't imagine how weird life would be without the chance to experience both genders and to have carried a child. And Gardner has several aces up his sleeve that let him, by the end of the book, position Tobin Cove's experience as a very specific and local experience that would not necessarily generalize to gender in society at large, which I thought was an ingenious way to avoid overreaching and excessive generalization. This is not a gender utopia; Fullin's world is rather patriarchal and strongly gender essentialist. The village was, in the past, ruled by a sort of religious fantatic who laid down very firm rules about the roles of men and women, and the village largely stuck to them, but since anyone can choose which gender they want to become, the gender essentialism is also undermined in an interesting way. It becomes more akin to a choice of careers rather than an innate quality, albeit with only two choices and with a permanent decision at the age of 20. Gardner complicates the situation further by introducing a neuter gender (at least that's what the characters call it; by physical description, hermaphrodite would be a more accurate description). People actually have three choices on their twentieth birthday, and although the Patriarch who ruled Tober Cove outlawed and banished all "neuts," it's still a choice. Near the start of Committment Hour one of those who chose the "neut" gender returns to Tober Cove in the company of a Spark Lord (thus making "it" the pronoun used by the natives untouchable and somewhat immune to the normal local prejudice). Committment Hour follows Fullin and his close friend and possible future wife or husband through their last day before their committment hour, a day complicated by the incessant curiosity of the observing Spark Lord and his companion. Gardner has some rather neat world building and some revelations in store; this is the sort of book where, by the end, the curtain has been fully pulled back and the audience gets to peer into the machinery. But most of the book is about the social and societal structure of Tober Cove, about how it feels to swap back and forth between genders (and how specific that is to Tober Cove's unique situation), and how this complicates interpersonal interactions. It's an immersive sort of book that puts the reader in Fullin's head and shows his (and her) comfort with the Tober Cove culture and discomfort with the life choices that he faces as part of committment. As with everything by him I've read, Gardner's tone in writing is unique and can take a bit of getting used to. His stories tend to have a light, almost flippant attitude with frequent touches of absurdist humor, which can give the erroneous impression that he isn't taking his story seriously. But there is depth beneath that tone. Fullin may treat some questions flippantly, but he gives them serious thought and works through the consequences. And I was delighted by how Fullin completely scuttled the Spark Lord's arrogant assumption of superiority around his scientific understanding of things Fullin treats as mythological. Committment Hour is different fare than the typical SF novel, with a lot of focus on an unusual domesticity and small village politics. The technology and the world building are mostly saved for the climax, although are quite satisfying when they finally come. It's primarily a thought-provoking treatment of gender that avoids overreaching by grounding the story in a specific situation. I found it a bit slow in places, and occasionally wanted the characters to stop being stupid and stop dithering, but I ended up enjoying it rather more than I expected. Mildly recommended. Rating: 7 out of 10

So we are at the beginning of this year's Debian Project Leader elections. And yes, after Stefano's long and (IMO) very successful DPL term, I feel as my voting machinery is somewhat stuck; it will not be so easy to get it back up to speed. Anyway, I have glanced over the three platforms, but only actually read 1.5 from the three DPL platforms. I know that whoever succeeds, I will be quite happy with the results. This year there are three runners for the post. I have worked in several teams with two of them, and would love to know better the third. In the same order as presented in the vote:

Gergely Nagy

I have not yet worked with Gergely, but enjoy reading him. The closest I have been to working with him was sketching a packaging tutorial during DebConf11, in Bosnia. Sadly, I was quite busy, and he picked up the complete workload And correspondingly, got the credits. I can say that Gergely has a very important quality, the ability to put in seductively easy words the most complex processes. So, yes, being the Debian Leader post a public-facing one, I am certain he has one of the important qualities.

Moray Allan

We have worked together organizing DebConf for many years, first loosely as orga-team members, and starting two years ago (and together with Holger Levsen) as formal delegates. I think our team is quite well balanced, and Moray plays an important role. Holger and I are sometimes anxious to take measures, measures that IMO would have proven disastrous more than once. Moray is often the voice of reason. Given that another one of the DPL's roles is to mediate in social conflicts and keep Debian working smoothly (or something close to it ;-) ), that is also a very important trait of a DPL, and I'm also sure Moray would shine as a good leader.

Lucas Nussbaum

I have long been part of the pkg-ruby-extras team (although I am way less active than what I used to, where Lucas often dazzles us with his intense streaks of activity. Among this group of three, I see Lucas firstly as the most technically oriented, the biggest implementer. Also, as the proactive bug-finder and team-herder. And yes, Lucas is maybe the most enthusiastic about the (always) important Making Debian Sexy point. So, if elected, I'm sure this facet will also make him shine

So, it's not that I'm trying to bribe our next DPL with sweet nice words about how interesting a person or how good a friend he is, but am trying to look at the election process as something different. It seems for me that we are going to choose which Debian do we want to pursue for this starting period. Now, for our soon-to-be-ex-DPL Stefano: As many will surely tell you (or already have): You rock. I truly enjoyed your DPL term, and there is much we should adopt and learn from your personality and leadership. And, although it has waned over the past few years, many people tend to publish their (stated?) vote during the campaigning period. I (think I) have never done so, and this time I will surely not do so. Choosing a DPL involves personal feelings, sympathies, and many non-objective things. And although I know nobody will feel hurt if I don't put them in the first place, I prefer not to expose such issues. I can only assure you that this year, "None of the above" will sink to the bottom of my ballot.

Daniel told me how to set up scroll wheel emulation on a Thinkpad. Presumably it works on other systems as well, but the magic numbers for xinput may be different. I wrote a script to set it up, and configure my GNOME session to run it upon login. The result: pressing the middle mouse button and moving the trackpoint up/down or left/right results in the applications receiving events as if a scroll wheel had been used. Very, very handy. Thanks, Daniel.

#!/bin/sh
set -eu
id=$(xinput list   sed -n '/TPPS\/2 IBM TrackPoint/s/.*id=\([0-9]\+\).*/\1/p')
emu=$(xinput list-props "$id"   
    sed -n '/Evdev Wheel Emulation (/s/.*(\([0-9]\+\)).*/\1/p')
but=$(xinput list-props "$id"   
    sed -n '/Evdev Wheel Emulation Button (/s/.*(\([0-9]\+\)).*/\1/p')
axs=$(xinput list-props "$id"   
    sed -n '/Evdev Wheel Emulation Axes (/s/.*(\([0-9]\+\)).*/\1/p')
xinput set-int-prop "$id" "$emu" 8 1
xinput set-int-prop "$id" "$but" 8 2
#xinput set-int-prop "$id" "$axs" 8 6 7 4 5

While reading the platforms for the upcoming DPL election, I read some statements about hearing from Project members about their experience within the Debian Project, so I took the chance to write some thoughts about my experience in one of our core teams, in which I have the privilege to be part of: the FTP Team. During NM process, my Application Manager asked me about some activities I could have involved into once I became a Debian Developer. I was fascinated by the hard work of the FTP folks when processing NEW packages (and I guess everybody reading these lines agree with me, remembering the happines of reading that wonderful ACCEPTED mail for their very first contribution to Debian, I still have it in my mailbox), so I decided I wanted to help out those folks to share a portion of their hard work. I committed errors, sometimes they were so silly I d be better to hide, but the team helped me to solve the mess I created. The thank you and kudos messages the FTP Team receives greatly overtake the frustration for my mistakes, and give the strength to keep up the good work FTP Team is just one of the dozens teams which do an awesome work for the Debian sake, every day. Don t be shy, or worried of being unsuitable or not skilled enough for the role. You ll never know until you try. And it could happen you really like the job, and you could feel sorry for have waited so long

Long time no write. A variety of things, including getting sick with a particularly bad cold (I'm still coughing up phlegm), led to my schedule and general life organization getting turned on its head, and I'm only slowly recovering. Work gets top priority (including a security release of OpenAFS), so I'm afraid non-work things such as reviews and journal posts (and Debian, and non-work-related software development, and conversations with friends...) have been getting second shrift. Hopefully this is finally starting to improve, and I have a block of time for working remotely coming up that should help. In the meantime, more books have, of course, been acquired. This particular order was mostly to get one book (The Making of the Indebted Man), which I'm going to read and discuss as part of a surprisingly fun political discussion about basic income guarantee and, somewhat by extension, Marxist analysis of capitalism. But it's impossible to buy just one book, similar to how it's impossible to eat just one potato chip: Neil Barofsky Bailout (non-fiction)
E. Gabriella Coleman Coding Freedom (non-fiction)
Joshua Foer Moonwalking with Einstein (non-fiction)
Maurizio Lazzarato The Making of the Indebted Man (non-fiction)
Isabel Wilkerson The Warmth of Other Suns (non-fiction) I of course preordered Coding Freedom and am quite looking forward to reading it, although it will surprise no one to hear that I have rather a long queue. The Warmth of Other Suns I picked up based on a recommendation by Ta-Nehisi Coates, whose writing for The Atlantic I wholeheartedly recommend. I have such a large pile of books that I've read but not yet reviewed that I cringe to think about it. But no progress will be made on that this evening (damn you, Benjamin Franklin! *shakes fist*). More tomorrow if I survive five and a half hours of scheduled forced social interaction.

the number of RC bugs concerning wheezy is going down, & here are my small contributions:

• #690152 src:bsaf: "bsaf: FTBFS: Test org.jdesktop.application.TaskMonitorTest failed"
  some triaging, later severity downgraded
• #699230 mahara: "Mahara: [CVE-2011-3642] (Flowplayer upstream) unpatched vulnerability"
  some triaging, then removed from testing
• #701115 owncloud: "owncloud: multiple vulnerabilities (oC-SA-2013-003, oC-SA-2013-004, oC-SA-2013-006)"
  sponsor NMU with security fixes by Prach Pongpanich, upload to DELAYED/2
• #701131 sa-learn-cyrus: "sa-learn-cyrus: directory vs. symlink conflict: /etc/mail/spamassassin"
  install file into "real" directory, upload to DELAYED/2

Last year, I invited you all to walk the plank with me, to follow me on a road, a road that even I was unsure where it led. I had a vision, I had ideas, but I had little to show for a plan. Even worse, some of my ideas, some of the things I've thought I knew, turned out to be wrong this past year. While my original plan was to pursue the goals I set out in my previous platform, I did none of that, and before I get to the meat of the platform, I owe you an explanation why: After walking the plank last year, I spent some time swimming to the shore, determined that no matter what, I will get things done. But how shall I do that? And when, with whom? Those questions needed an answer, therefore I took on a coat of an ordinary hacker, and started a journey to find the answers.That is how the past year's been spent: looking and learning. I was - and still am - following every major Debian list, I'm on IRC, absorbing all the information that fits into my tiny mind. I see now, that there's a lot more to be done than I thought last year, that some of the assumptions I made then, were wrong. And having spent a long time learning, it is my hope, that I did learn, and that this time, the plans I came up with will serve the same goal I had last year, better.That goal is as simple as growing Debian from a community of mostly technical folk to something much bigger, a community of enthusiastic, bright-eyed people who all want to do their part of making the world a better place. Big words, big task.The problemOne of the most fundamental problems with the project is that it is old, and hasn't grown up yet. We're still very focused on technical merit - don't get me wrong, that is important too, but there's much more we can do than that! We have tremendous amounts of talent, but pretty much every team is suffering from lack of people, and we seem to be slow and ineffective in recruiting new contributors (either from within the project, or outside of it), and even worse at keeping them motivated. This is not new, I worried about it last year, and I'm not the only one to see things this way, respectable members of the project expressed their pessimism publicly too.This is our biggest issue. We can be excellent at the technical level, but not being able to keep people motivated, failing to find new contributors is hurting us more and more, and it is my firm belief that without quick improvement in these areas, it won't be just me virtually walking the plank.On the flip side, we have every tool in our possession to steer ourselves into a better, brighter direction. We have excellent hackers, we have people who are terrific at communication, we have people who inspire others (just see the pattern on the dpl-game!), we have everything we need. Read on then, dear reader, and see my plan!Dancing on a tightropeTo tread on a path we have not taken so consciously before, we need to have a vision to strive for. A vision for the project as a whole, and a vision for ourselves, to see where we'd like to be a few years from now.As Stefano put it so well in his platform last year, Debian is a very unique member of the larger Free Software ecosystem - go and read his description, it can hardly be written better. This is the same vision I share, where Debian grows up to be much more than hundreds of talented people putting together a distribution. I want to see Debian becoming more than that, something that attracts not only the technical geniuses, but those who wield the power of speech and inspiration too, for these traits rarely go together.I envision a project, where people recognise each other's strengths, and make use of these strengths; where we can - and will - turn to each other, and work closely together, to achieve such good balance of skills of all kinds, as we already achieved in creating and maintaining the distribution itself.Let's dance!But alas, a vision is useless without a plan. That is a mistake I made last year, one that I will not repeat again. The approaches I choose may seem strange, or weird at first, but rest assured, they were carefully considered, and most of them tried out in a smaller setting. CommunicationWhat I've seen and experienced over the past year (and thinking back, far more than that - I just didn't know where to put the experience at that time) is that written communication is rarely the best medium to reach out to people. In this age we live in, written text reaches those who were already curious, it rarely reaches those who're still waiting for enlightenment. And even if it does, more often than not, there is no direct channel between the writer and the reader, which hurts not only the latency of the communication, but the quality too. Not to mention, that - however sad it may sound - the recipient is often too shy to engage.What does help, is face to face time. Events, where we can reach out to people, and receive immediate feedback, where we can notice the shy ones, and help them. Where we can immediately adapt to expectations.For this reason, I feel it necessary to encourage and help local teams in every possible way, to organise hackfests, code retreats, and all kinds of events that they feel will attract the bright-eyed youth (be them 20 or 80, it's the spirit that counts) we so direly need. These events need not be technical at all: a session about Debian publicity, about representing the project in press or on conferences is just as useful (if not more). Along with hackfests, we could - and should - have events focused on improving communication, for that is just as important.With strong focus placed on non-technical matters, I believe we can step on a path of rapid progress: my experience shows that techies and non-techies can inspire one another very well, much more than two techies would. With a focus on areas we are lacking in, we are indirectly improving those we are already good at. Inspiration & motivationBut finding new contributors, be them technically-sawwy or not is only part of the task, and the easier one too. It is much harder to keep people interested and motivated over a long period of time, than to find them once.On one hand, I would like to rely on those members of our community, who we all hold in high esteem (including, but not limited to those mentioned during the dpl-game). They know what keeps them going, they know what drives them away, we need to learn from that. I'd like to hear them speak more often, on conferences, if possible, as they are, I believe, a much more credible source than any elected official, at least in some situations.I'd also like to hear everyone's voice, from old members to the newest ones, I'd like to read - and if so need be, conduct - interviews with people who recently became Debian Developers, to hear about their experience, to learn what they think is good or bad, because a fresh view is just as important as a decade long experience.On the other hand, we need to act on the issues discovered too. We already know that quite a lot of trouble stems from lack of time, overburden and eventually burn out. We know the solution to this: recruit more people, and utilise the resources we do have better. Part of that can be solved by expanding our numbers, but for the other part, we may need deeper changes. What those may be, I cannot tell yet, there simply wasn't enough time to dig deeper, and I'm likely not the best person to undertake the task, either. I am, however, confident that we'll discover the solution as we travel along.The first step is gaining knowledge, without this, no further plans can be made. RecruitmentI already touched the recruitment part earlier, at least the how of the approach. What I'd like to expand on is the why, in particular: why encourage recruiting non-packaging contributors, when we are building a distribution, and we're lacking packaging manpower too?Let me answer those questions separately.First of all, I still like to think - but perhaps I am wrong - that we have an unbelievable amount of packaging manpower, which we fail to use to its full extent. We can use more, we always will be able to. But it also helps if we manage to put our existing resources to better use.And that is where non-packaging contributions come in. If we improve our skills in areas we're lacking in, that in turn, will improve the general quality of the project, which in turns improves morale, and a vibrant, well functioning, welcoming community attracts even more people, and keeps us motivated in the long run too.Mouse on the tightropeWith all that out, you may be wondering who I may be, and why you have not seen my name over the mailing lists in recent years. I'm not a terribly vocal person anymore, not a hot-headed teen I used to be some ten years ago. Most who know me, know me by my online nick name, algernon, and in most cases, I prefer that in real life too, for silly reasons I'd rather not dive into (but the primary one being that people have a hard time correctly pronouncing my name, and I have a hard time recognising my name unless pronounced the way I learnt it). Nevertheless, my name is Gergely Nagy, and I'm a recovering hacker, who intends to become a bachelor of (hungarian) arts, by majoring in Hungarian grammar & literature sometime in the next three to five years.Over the course of the past year, I also strived to observe and learn from exceptional leaders at my day job, because there, I have the advantage of meeting with them face to face, to interact with them on a daily basis. Fortunately for me, there are people among them from whom I learned a great deal about not only motivation, but about behind-the-scenes politics too - both a valuable lesson.And while I still have a tremendous amount of things to learn, I like to believe that I can do that. I know I can learn technical things extremely quickly (my day job depends on that, I would be out of a job if I failed at that), I'm positive that I can do the same in other areas as well, at least as long as it doesn't involve extreme amounts of economics. That proved to be a major barrier in the past.But back to the more important point: my organising, presentation and leading skills. I'm a co-organiser of the Budapest Clojure User Group meetups, I started to encourage GSoC participation at my day job last year (we participated thanks to OpenSUSE who gave us a slot), and I'm driving it this year, aiming to become a mentoring organisation of our own. I'm doing regular talks and presentations, participate in code retreats, meetups and other similar events where I can both practice and learn the art of interacting with people, and the fine art of organising events.

Last year, I invited you all to walk the plank with me, to follow me on a road, a road that even I was unsure where it led. I had a vision, I had ideas, but I had little to show for a plan. Even worse, some of my ideas, some of the things I've thought I knew, turned out to be wrong this past year. While my original plan was to pursue the goals I set out in my previous platform, I did none of that, and before I get to the meat of the platform, I owe you an explanation why: After walking the plank last year, I spent some time swimming to the shore, determined that no matter what, I will get things done. But how shall I do that? And when, with whom? Those questions needed an answer, therefore I took on a coat of an ordinary hacker, and started a journey to find the answers.That is how the past year's been spent: looking and learning. I was - and still am - following every major Debian list, I'm on IRC, absorbing all the information that fits into my tiny mind. I see now, that there's a lot more to be done than I thought last year, that some of the assumptions I made then, were wrong. And having spent a long time learning, it is my hope, that I did learn, and that this time, the plans I came up with will serve the same goal I had last year, better.That goal is as simple as growing Debian from a community of mostly technical folk to something much bigger, a community of enthusiastic, bright-eyed people who all want to do their part of making the world a better place. Big words, big task.The problemOne of the most fundamental problems with the project is that it is old, and hasn't grown up yet. We're still very focused on technical merit - don't get me wrong, that is important too, but there's much more we can do than that! We have tremendous amounts of talent, but pretty much every team is suffering from lack of people, and we seem to be slow and ineffective in recruiting new contributors (either from within the project, or outside of it), and even worse at keeping them motivated. This is not new, I worried about it last year, and I'm not the only one to see things this way, respectable members of the project expressed their pessimism publicly too.This is our biggest issue. We can be excellent at the technical level, but not being able to keep people motivated, failing to find new contributors is hurting us more and more, and it is my firm belief that without quick improvement in these areas, it won't be just me virtually walking the plank.On the flip side, we have every tool in our possession to steer ourselves into a better, brighter direction. We have excellent hackers, we have people who are terrific at communication, we have people who inspire others (just see the pattern on the dpl-game!), we have everything we need. Read on then, dear reader, and see my plan!Dancing on a tightropeTo tread on a path we have not taken so consciously before, we need to have a vision to strive for. A vision for the project as a whole, and a vision for ourselves, to see where we'd like to be a few years from now.As Stefano put it so well in his platform last year, Debian is a very unique member of the larger Free Software ecosystem - go and read his description, it can hardly be written better. This is the same vision I share, where Debian grows up to be much more than hundreds of talented people putting together a distribution. I want to see Debian becoming more than that, something that attracts not only the technical geniuses, but those who wield the power of speech and inspiration too, for these traits rarely go together.I envision a project, where people recognise each other's strengths, and make use of these strengths; where we can - and will - turn to each other, and work closely together, to achieve such good balance of skills of all kinds, as we already achieved in creating and maintaining the distribution itself.Let's dance!But alas, a vision is useless without a plan. That is a mistake I made last year, one that I will not repeat again. The approaches I choose may seem strange, or weird at first, but rest assured, they were carefully considered, and most of them tried out in a smaller setting. CommunicationWhat I've seen and experienced over the past year (and thinking back, far more than that - I just didn't know where to put the experience at that time) is that written communication is rarely the best medium to reach out to people. In this age we live in, written text reaches those who were already curious, it rarely reaches those who're still waiting for enlightenment. And even if it does, more often than not, there is no direct channel between the writer and the reader, which hurts not only the latency of the communication, but the quality too. Not to mention, that - however sad it may sound - the recipient is often too shy to engage.What does help, is face to face time. Events, where we can reach out to people, and receive immediate feedback, where we can notice the shy ones, and help them. Where we can immediately adapt to expectations.For this reason, I feel it necessary to encourage and help local teams in every possible way, to organise hackfests, code retreats, and all kinds of events that they feel will attract the bright-eyed youth (be them 20 or 80, it's the spirit that counts) we so direly need. These events need not be technical at all: a session about Debian publicity, about representing the project in press or on conferences is just as useful (if not more). Along with hackfests, we could - and should - have events focused on improving communication, for that is just as important.With strong focus placed on non-technical matters, I believe we can step on a path of rapid progress: my experience shows that techies and non-techies can inspire one another very well, much more than two techies would. With a focus on areas we are lacking in, we are indirectly improving those we are already good at. Inspiration & motivationBut finding new contributors, be them technically-sawwy or not is only part of the task, and the easier one too. It is much harder to keep people interested and motivated over a long period of time, than to find them once.On one hand, I would like to rely on those members of our community, who we all hold in high esteem (including, but not limited to those mentioned during the dpl-game). They know what keeps them going, they know what drives them away, we need to learn from that. I'd like to hear them speak more often, on conferences, if possible, as they are, I believe, a much more credible source than any elected official, at least in some situations.I'd also like to hear everyone's voice, from old members to the newest ones, I'd like to read - and if so need be, conduct - interviews with people who recently became Debian Developers, to hear about their experience, to learn what they think is good or bad, because a fresh view is just as important as a decade long experience.On the other hand, we need to act on the issues discovered too. We already know that quite a lot of trouble stems from lack of time, overburden and eventually burn out. We know the solution to this: recruit more people, and utilise the resources we do have better. Part of that can be solved by expanding our numbers, but for the other part, we may need deeper changes. What those may be, I cannot tell yet, there simply wasn't enough time to dig deeper, and I'm likely not the best person to undertake the task, either. I am, however, confident that we'll discover the solution as we travel along.The first step is gaining knowledge, without this, no further plans can be made. RecruitmentI already touched the recruitment part earlier, at least the how of the approach. What I'd like to expand on is the why, in particular: why encourage recruiting non-packaging contributors, when we are building a distribution, and we're lacking packaging manpower too?Let me answer those questions separately.First of all, I still like to think - but perhaps I am wrong - that we have an unbelievable amount of packaging manpower, which we fail to use to its full extent. We can use more, we always will be able to. But it also helps if we manage to put our existing resources to better use.And that is where non-packaging contributions come in. If we improve our skills in areas we're lacking in, that in turn, will improve the general quality of the project, which in turns improves morale, and a vibrant, well functioning, welcoming community attracts even more people, and keeps us motivated in the long run too.Mouse on the tightropeWith all that out, you may be wondering who I may be, and why you have not seen my name over the mailing lists in recent years. I'm not a terribly vocal person anymore, not a hot-headed teen I used to be some ten years ago. Most who know me, know me by my online nick name, algernon, and in most cases, I prefer that in real life too, for silly reasons I'd rather not dive into (but the primary one being that people have a hard time correctly pronouncing my name, and I have a hard time recognising my name unless pronounced the way I learnt it). Nevertheless, my name is Gergely Nagy, and I'm a recovering hacker, who intends to become a bachelor of (hungarian) arts, by majoring in Hungarian grammar & literature sometime in the next three to five years.Over the course of the past year, I also strived to observe and learn from exceptional leaders at my day job, because there, I have the advantage of meeting with them face to face, to interact with them on a daily basis. Fortunately for me, there are people among them from whom I learned a great deal about not only motivation, but about behind-the-scenes politics too - both a valuable lesson.And while I still have a tremendous amount of things to learn, I like to believe that I can do that. I know I can learn technical things extremely quickly (my day job depends on that, I would be out of a job if I failed at that), I'm positive that I can do the same in other areas as well, at least as long as it doesn't involve extreme amounts of economics. That proved to be a major barrier in the past.But back to the more important point: my organising, presentation and leading skills. I'm a co-organiser of the Budapest Clojure User Group meetups, I started to encourage GSoC participation at my day job last year (we participated thanks to OpenSUSE who gave us a slot), and I'm driving it this year, aiming to become a mentoring organisation of our own. I'm doing regular talks and presentations, participate in code retreats, meetups and other similar events where I can both practice and learn the art of interacting with people, and the fine art of organising events.

Partially because of Markdown being Github s markup format of choice, I enjoy writing documents in simple markup formats more and more. There s though one common annoyance with these formats compared to writing plain HTML The Annoyance They need to be rendered (i.e. more or less compiled) before you can view your outpourings rendered, e.g. in the web browser. So the workflow usually is:

1. Saving the current file in your favourite editor
2. Switch to terminal with commandline
3. Cursor up, Enter
4. Switch to your favourite web browser
5. Hit the reload button

Using a Specialized Editor with Live Preview One choice would be to use a specific editor with live rendering. The one I know in Debian (from Wheezy on) is ReText (Debian package retext). It supports Markdown and reStructuredText. But as with most simple GUI editors, I miss there many of the advanced editing commands possible with Emacs. Using Emacs Markdown Mode Then there is the Markdown Mode for Emacs (part of Debian s emacs-goodies-el package), where you can get a preview by pressing C-c C-c p. But for some reason this takes several seconds, opens a new buffer and window with the rendered HTML code and then starts (hardcoded) Firefox (which is not my preferred web browser). And if you do that a second time without closing Firefox first, it won t just reload the file but will open a new tab. You might think that just hitting reload should suffice. But no, the new tab has a different file name, so reload doesn t help. Additionally it may not use my preferred Markdown implementation. Meh. Well, I probably could fix all those issues with Markdown Mode, it s only Emacs Lisp. Heck, the called command is even configurable. But fixing at least four issues to fix one workflow annoyance? Maybe some other time, but not as long there are other nice choices Using inotifywait to Render on Write So everytime you save the currently edited file, you immediately want to rerender the same HTML file from it. This can be easily automated by using Linux inotify kernel subsystem which notices changes to the filesystem, and reports those to applications which ask for it. One such tool is inotifywait which can either output all or just specific events, or just exit if the first requested event occurs. With the latter it s easy to write a while loop on the commandline which regenerates a file after every write access. I use either Pandoc or Asciidoc for that since both generate full HTML pages including header and footer, but you can use that also with Markdown to render just the HTML body. Most browsers render it correctly anyway:

while inotifywait -q -e modify index.md; do pandoc -s -f markdown -t html -o index.html index.md; done
while inotifywait -q -e modify index.txt; do asciidoc index.txt; done
while inotifywait -q -e modify index.md; do markdown index.md > index.html; done

This solution is even editor- and build-system-agnostic (But not operating-system-agnostic.) inotifywait is part of inotify-tools, a useful set of commandline tools to interface with inotify. They re packaged in Debian as inotify-tools, too. Using mdpress for Markdown plus Impress.js based Slides The ruby-written mdpress is a special case of the previous case. It s a commandline tool to convert Markdown into Impress.js based slide shows and it has an option named --automatic which causes it to keep running and automatically update the presentation as soon as changes are made to the Markdown file. mdpress is not yet in Debian, but there s an ITP for it and Impress.js itself recently entered Debian as libjs-impress. Nevertheless, two dependencies (highlight.js, ITP ed, ruby-launchy, ITP ed) are still missing in Debian.

Aptitude ships documentation in 7 languages as HTML files. However the latest version available online was 0.4.11.2 from 2008 and hosted on the server by the previous, now unfortunately inactive Aptitude maintainer, and only covered 5 languages. This lack of up to date online documentation even caused others to put more up to date versions online. Nevertheless they age, too, and the one I m aware is not up to date for Wheezy. So the idea was born to keep an up to date version online on Aptitude s Alioth webspace (which currently redirects to a subdirectory of the previous maintainer s personal website). But unfortunately we, the current Aptitude Team, are still lacking administrative rights on Aptitude s Alioth project, which would be necessary to assign new team members who could work on that. As an intermediate step, there s now a (currently ;-) up to date Aptitude User s Manual online in all 7 languages at

http://people.debian.org/~abe/aptitude/ and English at

http://people.debian.org/~abe/aptitude/en/ As this location could also suffer from the same MIA issues as any other personal copy, the plan is to move this to somewhere under http://aptitude.alioth.debian.org/ as soon as we have full access to Aptitude s Alioth project. Our plans for then are:

• Redirects from http://people.debian.org/~abe/aptitude/ to e.g. http://aptitude.alioth.debian.org/doc/, so that all your links to or bookmarks of http://people.debian.org/~abe/aptitude/ are still valid. (This unfortunately won t work for jump marks to specific sections, just per file, i.e. chapter.)
• Set up a cron-job, which keeps the documentation in sync with the version of Aptitude in Unstable (and maybe also with Aptitude in Stable).

P.S.: Anyone interested in doing a German translation of the Aptitude User s Manual? Sources are in DocBook, i.e. XML, and available via Git.

This dent by M nica Ram rez Arceda finally gave me the energy to update the statistics about female participation in Debian, first published by Margarita Manterola back in 2010. So, here the new graph updated to February 2013. The necessary caveat is that is not easy (at least for me) to tell the gender just based on first names, so the actual numbers may be higher. In addition, you should be warned that there are some contributions not easily traceable: it's the case of translators, graphic artists and documentation writers, as well as event organizers. For instance, Beatrice Torracca doesn't appear in these stats, and she is the co-coordinator of the Italian translation team and a long term Debian (and free software in general) contributor. There was a proposal to better track non packaging contributors, but no news on that front yet (at least that I'm aware of). Sources:

• "first uploads": via UDD (except for the first two cases that are from old changelogs)
• DD and DM: taken from NM website

You can find the data used as well as the updated graph here. TODO:

• graph comparing male and female participation in Debian

I extended UDD's rcblog historical bug overview table until week 18, which is the last week of April. Let's hope we won't need that long and I will be able to delete half of those. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 761
  • Affecting wheezy: 174 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting wheezy and unstable: 105 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 32 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 7 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 67 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting wheezy only: 69 Those are already fixed in unstable, but the fix still needs to migrate to wheezy. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 40 bugs are in packages that are unblocked by the release team.
      • 29 bugs are in packages that are not unblocked.

How do we compare to the Squeeze release cycle?

Week	Squeeze	Wheezy	Diff
43	284 (213+71)	468 (332+136)	+184 (+119/+65)
44	261 (201+60)	408 (265+143)	+147 (+64/+83)
45	261 (205+56)	425 (291+134)	+164 (+86/+78)
46	271 (200+71)	401 (258+143)	+130 (+58/+72)
47	283 (209+74)	366 (221+145)	+83 (+12/+71)
48	256 (177+79)	378 (230+148)	+122 (+53/+69)
49	256 (180+76)	360 (216+155)	+104 (+36/+79)
50	204 (148+56)	339 (195+144)	+135 (+47/+90)
51	178 (124+54)	323 (190+133)	+145 (+66/+79)
52	115 (78+37)	289 (190+99)	+174 (+112/+62)
1	93 (60+33)	287 (171+116)	+194 (+111/+83)
2	82 (46+36)	271 (162+109)	+189 (+116/+73)
3	25 (15+10)	249 (165+84)	+224 (+150/+74)
4	14 (8+6)	244 (176+68)	+230 (+168/+62)
5	2 (0+2)	224 (132+92)	+222 (+132/+90)
6	release!	212 (129+83)	+212 (+129/+83)
7	release+1	194 (128+66)	+194 (+128/+66)
8	release+2	206 (144+62)	+206 (+144/+62)
9	release+3	174 (105+69)	+174 (+105/+62)

Graphical overview of bug stats thanks to azhag:

By using highly advanced and secret analytical tools (i.e. stupid correlation), I am guessing that Wheezy will be released in about six weeks. Week 16... mark my words. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 732
  • Affecting wheezy: 120 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting wheezy and unstable: 72 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 27 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 6 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 43 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting wheezy only: 48 Those are already fixed in unstable, but the fix still needs to migrate to wheezy. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 19 bugs are in packages that are unblocked by the release team.
      • 29 bugs are in packages that are not unblocked.

How do we compare to the Squeeze release cycle?

Week	Squeeze	Wheezy	Diff
43	284 (213+71)	468 (332+136)	+184 (+119/+65)
44	261 (201+60)	408 (265+143)	+147 (+64/+83)
45	261 (205+56)	425 (291+134)	+164 (+86/+78)
46	271 (200+71)	401 (258+143)	+130 (+58/+72)
47	283 (209+74)	366 (221+145)	+83 (+12/+71)
48	256 (177+79)	378 (230+148)	+122 (+53/+69)
49	256 (180+76)	360 (216+155)	+104 (+36/+79)
50	204 (148+56)	339 (195+144)	+135 (+47/+90)
51	178 (124+54)	323 (190+133)	+145 (+66/+79)
52	115 (78+37)	289 (190+99)	+174 (+112/+62)
1	93 (60+33)	287 (171+116)	+194 (+111/+83)
2	82 (46+36)	271 (162+109)	+189 (+116/+73)
3	25 (15+10)	249 (165+84)	+224 (+150/+74)
4	14 (8+6)	244 (176+68)	+230 (+168/+62)
5	2 (0+2)	224 (132+92)	+222 (+132/+90)
6	release!	212 (129+83)	+212 (+129/+83)
7	release+1	194 (128+66)	+194 (+128/+66)
8	release+2	206 (144+62)	+206 (+144/+62)
9	release+3	174 (105+69)	+174 (+105/+69)
10	release+4	120 (72+48)	+120 (+72/+48)
11	release+5
12	release+6
13	release+7
14	release+8
15	release+9
16	release+10
17	release+11
18	release+12

Graphical overview of bug stats thanks to azhag: