Dear friends of Debian,

this is my first post to Planet Debian. - The planet with the most geeky registration procedure in the known universe!

I proposed an alternative to topgit some days ago on the vcs-pkg.org list. Martin asked (and encouraged) me to give a better explanation of the idea, which I'll hereby try. Sorry for not giving any drawings, but I'm totally incapable of anything graphical.

Hopefully, I'll manage to come to the Debian Miniconf in Berlin. Then we could discuss the idea further and maybe even start implementing it. (Somebody would need to help me with my first steps in Perl then...)

The following text is available on github. Please help me expand it!

Design document for a patch management system on a DVCS

Requirements The system to implement manages patchsets. A patchset is a set of patches with a tree-ish dependency graph between the patches. There's one distinct root of this dependency graph. Patches are managed as branches with each branch representing a patch. Modification of a patch is done by a commit to the respective branch. A branch representing a patch as part of a patchset is called patchbranch. The patch of a patchbranch is created as the diff between the root of the patchbranch and the head. The most important management methods are:

• Export a patchset in different formats
  • quilt
  • a merged commit of all patches
  • a line of commits with each commit representing one patch
• Update a patchset against an updated root.
• Copy a patchset
• Delete a patchset from direct visibility while preserving all history about it
• Hide and unhide a patchset from direct visibility

Additional requirements:

• The system should be implementable on top of GIT, Mercurial and eventually Bazaar.
• The system must easily cope with multiple different and independent patchsets.
• All information about a patchset must be encoded in one distinct branch. Publishing this one branch must be sufficient to allow somebody else to recreate the patchset with all of its patchbranches.
• The system should not rely on the presence of hooks.
• The system should not require the addition of management files in patch branches (like .topmsg and .topdeps in topgit)
• The system must be easy to understand for a regular user of the underlying DVCS.
• The implementation may allow a patchset to depend on another patchset(s).

implementation

patchset meta branch A patchset meta branch holds all informations about one patchset. First, it holds references to the top commits of all patch branches in the form of parent references of commits. Thus pushing the patchset meta branch automatically also pushes all commits of all patch branches. Secondly, the patchset meta branch contains meta informations about the patchset. These meta informations are:

• The names of all patch branches together with the most recent commit identifier of a particular patch branch. Let's save this information in a file called branches.
• A message for each patch branch that explains the patch. These messages can be saved in the file tree as msg/$ PATCH-BRANCH-NAME
• References to the dependencies of the patch (other patches of the same patchset or the root of the patchset). This is also encoded in the file branches.

Since the patchset meta branch holds all this informations, it is possible, to delete all patch branches and recreate them from this informations. Although the commits of the patchset meta branches hold references to the patch branches, its file tree does not need to contain any files from the referenced patches. This may confuse the underlying DVCS, but the patch meta branch is not ment to be directly inspected.

The branches file A branches file for a fictive patchset could look like:

# patch branches without an explicit dependency depend on the root of the
# patchset tree
# A Root can be given as either a fix commit (seen here), a branch or a tag.
# A fixed commit or tag is useful to maintain a patchset against an older
# upstream version
ROOT: 6a8589de32d490806ab86432a3181370e65953ca
# A tag as a dependency
#ROOT: upstream/0.1.2
# A branch as a dependency
#ROOT: upstream
# A regular patch with it's name and last commit
BRANCH: debian/use-debian-jars-in-build-xml 4bab542c261ff1a1ae87151c3536f19ef02d7937
# two other regular patches
BRANCH: upstream-jira/HDFS-1234 a8e4af13106582ca1bfbbcaeb0537f73faf46d87
BRANCH: upstream-jira/MAP-REDUCE-007 e3426bcbcb2537478f851edcf6eb04b34f6c7106
# This patch depends on the above two patches
# The sha1 below the dependency patches references a merge commit of the two
# dependencies
BRANCH: upstream-jira/HDFS-008 517851aa829d77e09bc5e59985fed1b0aa339cc6
DEPENDENCIES:
  upstream-jira/HDFS-1234
  upstream-jira/MAP-REDUCE-007
    cc294f2e4773c4ff71efb83648a0e16835fca841
# A patch branch that belongs to the patch branch, but won't get exported (yet)
BRANCH: upstream-jira/HDFS-9999 74257905azgsa4689bc5e59985fed1b0aa339cc6
BRANCH-FLAGS: noexport

As I really liked saying why I think Open Game Art is a good project I decided to start a small serie of well done free (well not only software) projects. This time SFML got to be the one. SFML is, as the name already tells, a Simple and Fast Multimedia Library written in C++ but providing bindings for a whole bunch of other languages like Python, Ruby, C, D and others. Debian currently provides the original library as well as the C and Python bindings maintained by the Games Team and myself. On a side remark, SFML also uses my favourite License, zlib. What I really like about SFML is the readable code all through the project. Every time I was unsure what some function does having a look at the actual implementation (and some OpenGL and X11) knowledge turned out to be quite satisfactory. This is, of course, aided by the fact that SFML's development is driven by a single Developer, Laurent Gomila. On the rather weak points I'm still hoping the to-be-released 2.0 Version of SFML will introduce something like a stable API which it currently lacks (although the API has settled and there are no such huge changes as from 1.2 to 1.3 in recent updates any more). SFML also uses hand-made Makefiles for building (now supporting DESTDIR at least -- in some non-standard way) and has the usual load of embedded libraries which results in it's current load of patches. For a nice time burner make sure you take a look at the python binding's snake-like clone. It clearly misses some important aspects to form a full game but it's nice nontheless. I have a (not-quite) small SFML based Project myself, a forward ported game from my old DirectX days, however it's unfortunately not yet playable again und rather stalled at the moment due to lack of time. So much for SFML. If you feel like it feel free to join me on writing about well done pieces of software or just about pieces on how you think it should be done and tell us where you found it happening.

I'm thinking about distributed issue tracking systems that play nice with git. I don't care about other version control systems anymore :). I also prefer command line interfaces, because as commentators on the blog have mentioned, I'm a Luddite (in the imprecise, slang sense). So far I have found a few projects, and tried to guess how much of a going concern they are. Git Specific

• ticgit I don't know if this github at its best or worst, but the original project seems dormant and there are several forks. According the original author, this one is probably the best.
• git-issues Originally a rewrite of ticgit in python, it seems to to be active.

VCS Agnostic

• ditz Despite my not caring about other VCSs, ditz is VCS agnostic, just making files. Seems active.
• cil Takes a similar approach to ditz, is written in Perl rather than Ruby, and should release again any day now (hint, hint).

Sortof VCS Agnostic

• bugs everywhere is written in python. Works with Arch, Bazaar, Darcs, Git, and Mercurial. Last commit to the development repo was about 6 months ago.
• simple defects has Git and Darcs integration. It seems active. It's written by bestpractical people, so no surprise it is written in Perl.

On FOSDEM 2010 we agreed on several bigger changes in phpMyAdmin. The two of them were my proposals and I had to take care of them - migration to Git and start to use Gettext based system for translating phpMyAdmin. The migration to Git was quite straightforward and went alive on 11th of March. There were few tiny issues afterwards, but I think everything went quite smoothly and we can happily use it right now (I especially enjoy using feature branches). I've also written little guideline to document best practices to use in our repository After we went to Git, I immediately started on another big transition - the goal is to use standard po files for translations. The obvious solution is to use gettext for that, however the one in PHP is not really in good shape to use, so we went with php-gettext. Today I just merged gettext branch to master so it is also done (see information for developers and translators for more details regarding this). So now these big tasks are done and I can focus on daily issues connected with GSoC and other areas.

It looks like being separate organisation in GSoC definitely brings more attention than last years where we were under MySQL. Hopefully this will allow us to choose really enthusiastic students who will do their work properly and without much kicking. So if you are interested in participation in GSoC 2010 with phpMyAdmin, please take care filling up the proposal and showing us some previous contributions (see student checklist for more hints) in order to be selected. The dark side of this is enormous increase of mails on our devel mailing list and combined with my illness last week and vacation few days before, it makes constant volume of 50 unread mails there for me :-).

I've been pondering this subject for a while, and I think I'm finally ready to write about it.
Tcl was, for many years, my go-to language of choice. It's still near and dear to me in many ways, and I even worked on a portion of a book about it ( http://journal.dedasys.com/2009/09/15/tcl-and-the-tk-toolkit-2nd-edition ). However, examining what "went wrong" is quite interesting, if one attempts, as much as possible, a dispassionate, analytical approach that aims to gain knowledge, rather than assign blame or paper over real defects with a rose-colored vision of things. It has made me consider, and learn, about a variety of aspects of the software industry, such as economics and marketing, that I had not previously been interested in. Indeed, my thesis is that Tcl and Tk's problems primarily stem from economic and marketing (human) factors, rather than any serious defects with the technology itself. Before we go further, I want to say that Tcl is not "dying". It is still a very widely used language, with a lot of code in production, and, importantly, a healthy, diverse, and highly talented core team that is dedicated to maintaining and improving the code. That said, since its "heyday" in the late 90ies, it has not ... "thrived", I guess we can say. I would also like to state that "hindsight is 20-20" - it's easy to criticize after the fact, and not nearly so easy to do the right thing in the right moment. This was one reason why I was reticent to write this article. Let me repeat that I am writing it not out of malice or frustration (I went through a "frustrated" phase, but that's in the past), but because at this point I think it's a genuinely interesting "case history" of a the rise and gentle decline of a widely used software system, and that there is a lot to be learned. At the height of its popularity, Tcl was up there with Perl, which was the scripting language in those days. Perl, Tcl, and Python were often mentioned together. Ruby existed, but was virtually unknown outside of Japan. PHP was on the rise, but still hadn't really come into its own. Lua hadn't really carved out a niche for itself yet, either. Tcl is no longer one of the popular languages, these days, so to say it hasn't had problems is to bury one's head in the sand: it has fallen in terms of popularity. To examine what went wrong, we should probably start off with what went right:

• Tk. This was probably the biggest draw. Easy, cross platform GUI's were, and are, a huge reason for the interest in Tcl. Tk is actually a separate bit of code, but since many of the widgets are scripted in Tcl, the two are joined at the hip. Still, though, Tk is compelling enough that it's utilized as the default GUI library for half a dozen other languages.
• A simple, powerful language. Tcl is easy to understand and get started with. It borrows from many languages, but is not an esoteric creation from the CS department that is inaccessible to average programmers.
• Easily embeddable/extendable. Remember that Tcl was created in the late 80ies, when computers were orders of magnitude less powerful than today. This meant that fewer tasks could be accomplished via scripting languages, but a scripting language that let you write routines in C, or, conversely, let the main C program execute bits of script code from time to time was a very sensible idea. Tcl still has one of the best, and most extensive C API's in the game.
• An event loop. Lately, systems like Python's "twisted", and node.js have made event-driven programming popular again, but Tcl has had it for years.
• BSD license. This meant that you could integrate Tcl in your proprietary code without worrying about the GPL or any other legal issues.

These features led to Tcl being widely used, from Cisco routers to advanced television graphics generation programs to the AOLserver web server, which was busy serving out large quantities of dynamic web pages when many of us were still fiddling around with comparatively slow and clunky CGI programs in Perl. Note also that there have been a lot of cool things to have gone into Tcl in the mean time. It has a lot of impressive features; many more than most people realize, and has had a lot of them for a while. Check out http://www.tcl.tk to learn more about the "good stuff". But that's not the point of this article... There was a healthy, active community of developers producing lots of interesting add-ons for the language, and working on the language itself. This culminated in its adoption by Sun Microsystems, which hired the language's creator, Dr. John Ousterhout, and a team of people, who added a lot of great features to the language. Quoting from Ousterhout's history of Tcl page:

The additional resources provided by Sun allowed us to make major improvements to Tcl and Tk. Scott Stanton and Ray Johnson ported Tcl and Tk to Windows and the Macintosh, so that Tcl became an outstanding cross-platform development environment; Windows quickly came to be the most common platform. Jacob Levy and Scott Stanton overhauled the I/O system and added socket support, so that Tcl could easily be used for a variety of network applications. Brian Lewis built a bytecode compiler for Tcl scripts, which provided speedups of as much as a factor of 10x. Jacob Levy implemented Safe-Tcl, a powerful security model that allows untrusted scripts to be evaluated safely. Jacob Levy and Laurent Demailly built a Tcl plugin, so that Tcl scripts can be evaluated in a Web browser, and we created Jacl and TclBlend, which allow Tcl and Java to work closely together. We added many other smaller improvements, such as dynamic loading, namespaces, time and date support, binary I/O, additional file manipulation commands, and an improved font mechanism. Unfortunately, after several years, Sun decided that they wanted to promote one and only one language. And that language was Java. So Ousterhout and many people from his team decamped to a startup that Ousterhout founded, called Scriptics, where the Tcl and Tk innovations continued:

In 1998, Scriptics made several patch releases for Tcl 8.0 to fix bugs and add small new features, such as a better support for the [incr Tcl] extension. In April 1999, Scriptics made its first major open source release, Tcl/Tk 8.1. This release added Unicode support (for internationalization), thread safety (for multi-threaded server applications), and an all-new regular expression package by Henry Spencer that included many new features as well as Unicode support.
However, as many a company based around open source was to find later, it's a tough space to be in. Scriptics changed its name to Ajuba, and was eventually sold (at a healthy profit, apparently, making it a relative dot com success story, all in all) to Interwoven, for the "B2B" technology that Ajuba had developed. Interwoven was not interested in Tcl, particularly, so, to create a system for the ongoing development and governance of the language, the "Tcl Core Team" was created. This was something of a blow to Tcl, but certainly not fatal: Perl, Python, Ruby, PHP, Lua have all had some paid corporate support, but it has by no means been constant, or included large teams. At the same time in the late 90ies, open source was really starting to take off in general. Programmers were making all kinds of progress, and had begun to make Linux into what is today the world's most widely used server platform, and laying the groundwork for the KDE and Gnome desktops. While these may still not be widely used, they are for the most part very polished systems, and leaps and bounds better than what passed for the 'Unix desktop' experience in the 90ies. One of the key bits of work that was added to Tk was to make it look pretty good on Microsoft Windows systems. This was in an time when the "enterprisey" folks were turning away from Unix in the form of AIX, Solaris, HPUX, et al. and taking up NT as the platform of choice, so it was in some ways sensible to make Tk work well there, and in any case as a cross platform GUI toolkit, it ought to work well there in any case. And, on the Unix side, Tk emulated the expensive, professional Motif look and feel that serious Unix programmers used. What could go wrong? As Gnome and KDE continued to mature, though, what would become one of Tk's major (in my opinion) marketing blunders took root. I have it on good authority, from someone who was there in the office, that the Scriptics guys working on Tcl and Tk viewed Gnome and KDE (and the Gtk and Qt toolkits) as not really worth their while. To be fair, since Tk has always been under a liberal BSD style license, the Qt toolkit has always been "off limits". Still, though, the attitude was that Tk was a standalone system, and since it ran on pretty much any Unix system, it didn't need to bother with Gnome or KDE. Gradually, though, as more and more people used Gnome and KDE exclusively on Linux, the Tk look and feel began to look more and more antiquated, a relic from the 1990ies when Motif (which has since pretty much disappeared) was king. Tk applications started to really stand out by not looking at all like the rest of the operating system. And, while Linux may not be responsible for a vast portion of the world's desktops, it is widely used by developers, who were turned off by the increasingly creaky look of the Tk applications they saw. Tk is and was actually a fairly flexible system, and it would have been possible to tweak the look and feel to make it look a bit better on Linux, without even doing any major work. Maybe not perfect, but certainly better looking. Nothing happened, though. Another problem was that Tk and Tcl made it so easy to create GUIs that anyone could, and did, despite, in many cases, a complete lack of design skills. You can't particularly blame the tools for how they're used, but there was certainly a cultural problem: if you read most of the early Tcl and Tk books, and even many of the modern ones, there are hundreds of pages dedicated to exactly how to use Tk, but few to none explaining even basic user interface concepts, or even admonitions to the user to seek out that knowledge prior to attempting a serious GUI program. The end result is that a lot of Tk programs, besides just looking "old fashioned" had fairly poor user interfaces because they were made by programmers who did not have a UI/design culture. Contrast that with Gnome and KDE, which have made a point of focusing on how to make a good GUI for their systems, complete with guidelines about how applications should behave. It may have taken them some time to get things right, but they have done a lot to try and instill a culture of creating high quality, well-integrated GUI's that are consistent with the system where they run. Lately, there has been a lot of work to update the Tk look and feel, and it has finally started to bear fruit. However, in terms of marketing, the damage has already been done: the image of "old, crufty Tk" has been firmly planted in countless developers' minds, and no amount of facts are going to displace it in the near future. Another problem Tcl faced, as it grew, was the tug-of-war between those wishing to see it small, light, and easy to distribute embedded within some other program, and those wishing it to become a "full-fledged" programming language, with lots of tools for solving every day programs. Unfortunately, that tug of war seems to have left it somewhere in the middle. Lua is probably more popular these days as an embedded language, because it is very small, and very fast, and doesn't have as much "baggage" as Tcl. Meaning, of course, that it doesn't do as much as Tcl either, but for a system where one merely wishes to embed a scripting language, without much 'extra stuff', Tcl's extra functionality is perhaps a burden rather than a bonus. On the other hand, while Perl was happily chugging along with their CPAN system for distributing code, giving users easy access to a huge array of add-on functionality, and Python was building up a "batteries included" distribution, that included a lot of very useful software straight out of the box. Tcl, on the other hand, chose to keep the core distribution smallish, and only lately has got some semblance of a packaging and distribution system, that is, however, run by ActiveState, and is (at least according to a cursory glance at the Tcl'ers wiki), not even fully open source. The lack of a good distribution mechanism, and, in the meantime, eschewing a larger, batteries-included main distribution left Tcl users with a language that, out of the box, did significantly less than the competition. Technically, a Python style "big" distribution would not have been all that difficult, so once again, I think this is a marketing problem: a failure of the Tcl Core Team to observe the "market", assess what users needed, and act on it in a timely manner. Somewhat related to the large Tcl vs small Tcl issue was one particular extension, or extensions to the language that was noticeably absent: a system for writing "object oriented" code. Tcl, at heart, will never be an OO language through and through, like Ruby or Smalltalk, but that doesn't mean that an OO system for it is not a useful way of organizing larger Tcl systems. Indeed, Tcl's syntax is flexible enough that it's possible to write an OO system in Tcl itself, or, optimizing for speed, utilizing the extensive C API in order to create new commands. Over the years, a number of such systems have arisen, the most well-known being "Incr Tcl" (a play on the incr command, which is akin to += 1 in languages like C). However, none of these extensions was ever included with the standard Tcl distribution or somehow "blessed" as the official OO system for Tcl. This meant that a newcomer to Tcl wishing to organize their code according to OO principles had to pick a system to use from several competing options. And of course, newcomers are the least able to judge a complex feature like that in a language, making it a doubly stressful choice. Furthermore, even experienced Tcl programmers who wanted to share their code could not utilize an OO system if they wanted their code to work with just standard Tcl. Also, if their code had a dependancy on some OO system, it would require the user to download not only the extension in question, but the OO system it was built on, which, naturally, might conflict with whatever OO system the user had already selected! As of Tcl 8.6, thanks to the work of Donal Fellows, Tcl is finally integrating the building blocks of an OO system in the core itself, but this effort is probably something like 10 years too late. Some other more or less minor things that have taken too long to get integrated in the Tcl or Tk distributions include the PNG format (still not there in a production release of Tcl), a readline-based command line (Tkcon is nice, but not a replacement for simply being able to type "tclsh" and get a nice, functional shell like Python, Ruby and most other languages have. This could easily lead to a bad first experience for someone trying out Tcl). Tcl also took too long to integrate a first-class hash type (accessed with the 'dict' command), which only appeared in 8.5. Its "arrays" aren't bad, but don't quite have the full power of a hash table as dict implements them. Once again, the code to do these things was/is out there, it has just been a matter of integrating it into Tcl and Tk, which has been a slow process. One actual technical problem that Tcl faces is the concept that all values must be representable as a string. This is more or less ok for things like lists, hash tables or numbers, but is problematic when the user wishes to represent a value that simply isn't a string. A basic example is a file handle, which at the C API level is a FILE*. How does Tcl get around this? It keeps an internal hash table with a Tcl-script accessible string, such as "file5" that points to a FILE * value that is used internally by file commands. This works pretty well, but there is a big "but": since you can compose a string like "file5" at any time, that must be able to access the actual file pointer, you can't do any sort of "garbage collection" to determine when to clean things up automatically. Other languages have explicit references to resources, so the program "knows" when a resource is no longer referenced by the rest of the program, and can clean it up. Therefore, the programmer must explicity free any resources referenced this way. This explanation is simplifying things somewhat, but it is something I view as a technical problem with Tcl. If you've been following along, you've noticed a lot of "these days" and "recently". That's because Tcl is still very actively developed, with a lot of new ideas going into it. However, if you look at the release dates, it seems that after Ajuba was sold off, and Ousterhout pretty much abandoned an active role in the language for good, placing it in the hands of the Tcl Core Team, there was a lull in the momentum, with Tcl 8.5 taking 5 years to be released. This is actually, in my opinion, an interesting phenomenon in languages: you risk hitting some kind of local maximum when your language is popular enough to have a lot of users who will be angry if things are changed or accidentally broken in the course of big upheavals. So you have to slow down, go carefully, and not rock the boat too much. On the other hand, there is an opportunity cost in that newer languages with less to lose can race ahead of you, adding all kinds of cool and handy new things, or simply fix and remove "broken" features. Erlang is another system that has, in my opinion, suffered from this problem to some degree, but this article is long enough already! Once again, though, not really a technical issue, but a problem with how the code was managed (and not an easy one to solve, at that). A Tcl failure that I was personally involved with was the web infrastructure. What went on to become Apache Rivet was one of the first open source Apache/Tcl projects, and was actually quite a nice system: it was significantly faster than PHP, and of course made use of Tcl, which at the time had a large library of existing code, and could be easily repurposed for projects outside the web (or the other way around: non-web code could be brought in to a web-based project). One thing I ought to have done differently with the Apache Rivet project was listen to the wise advice of Damon Courtney, my "partner in crime" on the project, who wanted to see Apache Rivet have a fairly "fat" distribution with lots of useful goodies. Rails and Django, these days, have shown that that's a sensible approach, rather than relying on lots of little extensions that the user has to go around and collect. The code was out there, I should have helped make Rivet do more "out of the box". A problem that is and it isn't: the syntax. Tcl's syntax is amazingly flexible. Since everything is a command, you can write new commands in Tcl itself - and that goes for control structures, too! For instance, Tcl has a "while" command, but no "do ... while". It's very easy to implement that in Tcl itself. You simply can't do that in most "everyday" languages. However, this comes at something of a "cost". The syntax, for your average programmer who doesn't want to go too far out of their comfort zone, is perhaps a little bit further afield from the C family of languages than they would prefer. Still though, a "human" problem, rather than a technical one. Perhaps, sadly, the message is that you'd better not "scare" people when introducing a new language, by showing people something that doesn't look at least a little bit familiar. Conclusions? First and foremost, that, gradually, Tcl and Tk continue to be improved. However, if one visits developer forums, there are also a lot of negatives associated with the Tcl and Tk "brands", and I am not sure if it will be possible to rectify that. So what can we learn from the rise and subsequent "stagnation" of Tcl?

• Success in the first place came from doing one particular thing very well, and making it a lot easier than other existing systems at the time. That's a good strategy.
• Not staying up to date can be deadly. Of course it can be tricky to know what's a genuine trend, and what's just a fad, in this industry, and picking the right things to stay up to date with can be tricky. That said, there are a number of areas where Tcl and Tk failed to follow what became very clear directions until way too late.
• Do your best not to get trapped between existing users who don't want to rock the boat, and don't lose your agility and ability to iterate with the system you're developing. Long delays between releases can be deadly.
• Don't lose touch with your "roots". In this case, the open source community that is a "breeding ground" for new developers and projects. Tcl and Tk became passe in that environment, which has led to its lack of adoption for new projects not only in the world of open source, but in businesses as well.
• Don't isolate yourself: Tcl and Tk stopped appearing at a lot of the open source conferences and events and in magazines/books/articles online, either because with no figurehead/leader to invite there was less interest in speakers and authors, or because the rest of the Tcl Core Team wasn't particularly engaged, or for whatever other reason. This created something of a negative feedback loop where Tcl and Tk were things associated with the past, rather than something currently talked about and discussed.

Fourteen months after the renaming of the Free/Open Source code of GForge 4.x to the new FusionForge name, we're pleased to announce version 5.0. As mentioned in the release notes, this is still an incremental step over version 4.8 rather than a revolution, but the changes are important enough, and numerous enough, that we felt it justified to bump the major version number. Major improvements, beyond a host of bugfixes, include:

• a rewrite of the version control integration (with support for Bazaar, Darcs, Git and Mercurial in addition to the traditional CVS and Subversion);
• a much better integration of Mediawiki (one wiki, with its own set of permissions, per project);
• a cleaner database layer, more robust against SQL injections;
• configurable display for the trackers;
• more powerful tracker engine, with configurable workflows;
• a rework of the default theme, with better accessibility.

FusionForge 5.0 now also includes new plugins that were previously only floating around (or completely private):

• projectlabels gives a simple way of adding bits of HTML onto project description pages, so the forge admin can, for instance, highlight a project of the month ;
• extratabs allows a project to define new tabs in its pages, pointing at external resources;
• globalsearch is a first step in the federation of forges concept, whereby a project search can be conducted on several forges at once;
• contribtracker allows a forge to prominently display major contributors to projects, to give them visibility beyond the simple commit logs.

These plugins, as well as a large part of the improvements in the trackers and the rewritten Mediawiki plugin, are a direct consequence of the upstreaming of work having been done in private instances of forges. We're happy to note that this goal of ours (to merge local patches into the central repository when it makes sense) seems to be working well. For the record, this 5.0 release includes work and plugins that were reintegrated from sources such as Alcatel-Lucent, Adullact and AdaCore. This release is also the first to have had the benefit of automated testing during the whole cycle. Coverage isn't 100 % yet, but the existing unit tests and functional tests help us be confident in the quality of the release. We'll keep adding more tests as time passes, of course. Looking back at the initial goals stated when the project started, we seem to be on the right track:

• stable release pushed out: check (this is the third one, not counting minor releases);
• new plugins merged: check;
• automated testing: check;
• external contributions merged: check;
• explicit governance model and release process: sort-of (there's still a cabal, but it's partially documented).

We still need to work on the database schema and the cross-distro part, as well as cross-forge interoperability. The good news is that work is happening on these fronts already. And with almost 2500 commits, we truly seem to have accomplished at least one of the (implicit) goals: to bring development back to a healthy state. And we're far from being out of ideas for the future, so there's a lot of good stuff still cooking!

Marc Haber:

Do you see the diminishing care for our Core infrastructure as a problem? Do you have any idea how do sensibilize our new blood for the fact that "new packages" doesn't help Debian if our Core stuff is diminishing? I know that this is not exactly within the power of the DPL, but do you think that you, as DPL, can help speeding up Core development again?

Note: "core infrastructure" here refers to dpkg and apt. I am seeing numerous projects across the free software world struggle with a lack of contributors, and wonder why they cannot get anyone to help them. In most cases, I think there are hints about why people might feel disenfranchised by a particular development process, and in most cases, I think the people in charge are mostly unwilling to change the way that they have been doing things for years and years just to accommodate potential contributors. I think this is particularly true of projects where there is a dictatorship or a single gatekeeper for all VCS repository commits. Frequently these things seem to work themselves out after a long time. Old people leave, new people come in. Sometimes it is peaceful, sometimes it is violent. Rarely does it result in structural improvements. I do not know why there is lack of manpower on dpkg and apt right now. I know I tried to make a change to dpkg a few months ago and was unable to do so, partly due to the codebase and partly due to important information existing only in Guillem's mind. In the end, I had to just wait for Guillem to do it, which he helpfully did, and now we have libdpkg-dev in experimental, with one reverse build-dep. Had I been able to make the change myself, it is unclear whether I would have made any other contributions; that was the only itch I needed scratched, and I have plenty of other things to work on. So even though I found it near-impossible to contribute to dpkg in this way, I don't think that I'm excluded. So as DPL I would first try to determine why there might not be enough contributors to dpkg and apt, or why the existing contributors are not performing up to your standards. This could be an instance where I would solicit private communication from people who might have potentially-valuable information that they do not wish to communicate in public for fear of hurting someone's feelings. This does not mean that I would try to resolve these issues behind the scenes, because I consider that to be a dangerous and potentially-harmful tactic. Given a reasonable theory about why the problem exists, I would then proceed to encourage the resolution of that problem. I also think that some package maintenance teams may share some issues with some core teams and even the project at large, and addressing the more general problems could lead to relief in many areas. Specifically I would name problems related to ego and teamwork, which is a theme on which I plan to elaborate later.

Russ Allbery:

Do you have any thoughts about how to resolve release issues with less hurt and negative impact to the project all around?

I sure do. There has been a trend over many years to conflate the release management role with many other things: QA work, buildd work, ftpmaster-like work (I mean britney here), and in some cases I would even say DPL work. If we relegate release management to a strictly managerial role, I am certain that much of the stress, tension, and burnout will be mitigated. This means putting more access into the hands of many people, which is a good thing anyway. A release manager's job should be to say when a release is ready, what should and should not be in that release, and potentially some coordination with other developers, who are almost their equals. There will still be social conflict when the spirit of teamwork and cooperation is overcome by other factors, but I can conceive of a point where even that would not happen. Raphael Hertzog:

What do you think of this and would you be ready to withdraw a delegation for a delegate that behaved badly towards another DD (even outside of his delegated role), that has been warned once by you and that did it again later on? Do you think we can draft a code of conduct for Debian and do you think you can ensure that it would be respected by delegates?

I do not think that any long-term delegations should exist. I think that if they do, we have a structural problem which should be addressed in another way. Therefore I do not think it should be a big deal to withdraw a delegation for any legitimate reason, and if we are trying to force people to behave better (by a definition I agree with), then it seems reasonable to withdraw a delegation for bad behavior. Of course I would include ignoring people and having secret meetings in Vancouver as bad behavior, so that is perhaps not what you are getting at. I am not particularly in love with any formal codes of conduct, but I do think it is reasonable to hold DPL delegates or anyone who holds privileged positions of power to a much higher standard of behavior than the standard DD. With power should come responsibility, and all that. Presumably I would not delegate anyone who would place self and ego ahead of the well-being of the project, and presumably if there were a formal code of conduct or set of guidelines for delegates, those principles would align.

Raphael Hertzog:

Imagine a DD contacts you, she wants to setup an infrastructure to finance Debian related projects (i.e. paying people to enable them to work on the projects that they'd like to do for Debian) but she wants to avoid the main mistakes made during Dunc-Tank; in her project: - everybody can propose projects to be financed - the projects to be financed are selected by the Debian developers and by the donors - eligible projects can only concern new developements and not recurring tasks

I am imagining that this contact took place in public. I see very few legitimate and good reasons to approach the DPL privately, and as DPL I would encourage people to to work toward transparency unless there were very good reasons to do otherwise. I would begin by telling her about the beauty of Debian as a gift economy community, and point out how great it is that I do not need to pay people to respond to my bug reports, apply my patches, release new versions, or develop any code not funded by corporate sponsors. I would recount my recent experience with a different free software community, where there was much talk of the motivational power of money, and how best to link PayPal to bug tracking systems and write a boilerplate email response template suggesting a donation of $5,000 to help facilitate the development of any feature requests. I would confess my suspicion that if this trend continues, any goodness in that community will be driven elsewhere, and the gift economy, which I believe to be a very important basis for free software, will be severely undermined. When I have completed my feeble attempt at political persuasion, if she is still firm and stubborn in her desire to proceed (and when monetary greed is involved, I expect this kind of stubbornness), I would suggest the following points:

• Keep it as far away from Debian as possible: if these projects can be accomplished upstream or externally, it is better for Debian if done that way.
• Ensure that the people saying that the work is necessary are not the same as the people who are the only ones with access to do the work and thus the only people getting paid, because when those decisions are arbitrary it reeks of corruption.
• There should be as little subjectivity as possible. It should be utterly clear when someone has completed the work and earned the monetary prize. There should be no discretion on the part of persons with privileged positions in Debian, especially if friendships or other personal relationships are involved.

Then I would ask her once again not to do anything like this. Dmitrijs Ledkovs:

Please finish "In ten years I'd like Debian...."

In ten years I'd like Debian to still be my favorite operating system. In ten years I'd like Debian to be egalitarian and cooperative. In ten years I'd like Debian to be completely free software, without a non-free section.

Jane McGoningal gave an interesting TED talk about how Online Gaming can Make a Better World [1]. One of her points is that there is no unemployment in games such as World of Warcraft, there is always a world saving mission available to you which is just within reach of your skill level and no-one is assigned a mission that they can t possibly do. It seems to me that the free software development community has a similar issue, there are always missions available at all skill levels. Our challenge is to find ways to encourage people to accept the missions and to provide them appropriate levels of support to encourage them on their path to an epic win . Choosing a suitable mission is a particularly difficult problem as you often don t know how difficult a task will be until you are more than half complete. Jane makes points about humans being happier when working hard and a desire for epic meaning . She says that it s a problem that gamers believe that they can change a virtual world but not the real world . If you change the virtual world of software development then that changes the real-world . Jane cites Herodotus as reporting a kingdom that was gripped in a famine for 18 years where the king instituted a policy of playing games and eating on alternate days with the aim being that the games would distract people from their hunger. I m sure that I m not the only person who s gone without food or water for a day because of being too busy coding She has a lot of other interesting points and I recommend that you read the Institute For The Future [2] web site for more background information. Now my question is, how can we encourage programmers to start doing Free Software and Open Source development and achieving some Epic Wins? I don t claim to have good answers and I would appreciate any suggestions. If you blog about this please leave a comment on this post to direct readers to your blog.

• [1] http://www.ted.com/talks/jane_mcgonigal_gaming_can_make_a_better_world.html
• [2] http://www.iftf.org/

A while back, I promised some people that I would answer the campaign questions on -vote despite not being on the ballot. Many things came up to pre-empt me, including a short-lived surprise stint on the Release Team. I am still a bit behind on bug reports and such, but it might be inappropriate to start answering after the official campaign period has closed, so here is a start. J rg Jaspert:

Do you plan on taking on a "2IC" or a team?

I do not. I do not believe that either option is a good idea to begin with, and even if I did, I would not be in favor of undermining the Constitution by making an end run around it in this fashion. Martin Zobel-Helas:

The Debian Project receives quite a number of monetary donations as well as contributions in kind via several umbrella organization like SPI, ffis, debian.ch, etc. a) What do you think are valid goals to spend this money on? b) How would you think is a valid way to thank (hardware) contributors? b) What qualifies a contributor to become a "Debian Partner"? What qualifies a "Debian Partner"?

a) I think that it is important not to spend money on things that only benefit a single person or small group, such as ex-post facto legal defenses, core team travel expenses, or equipment for select persons. I would consider valid expenditures to be only those that directly benefit Debian as a whole. b) Ideally, contributors, whether they be hardware donors or developers or anything else, would be motivated solely out of doing good for the project and community, and not be seeking recognition, praise, power, or favors in return. However, since it is considered acceptable to have other motives, I think it fairly appropriate to display logos and give recognition on the Partners page. b) If I had my druthers, I would reserve the term Partners for those organizations who were fully aligned with us in a common goal. In the absence of such, though, the current usage seems fine. Paul Wise:

How much time do you currently devote to Debian? How will that amount of time change for the DPL term? How will you balance your DPL time and time for other Debian activities.

My time commitment varies due to a combination of external factors and Debian-related motivation. Since I have been slowly scaling back my involvement over the past several years, and unless you assume that the DPL role is inherently demotivating, I would presume to be spending about the same time or more on Debian if elected. I will be orphaning some more packages after squeeze is released, regardless of the outcome of the election. I would definitely not run if I doubted my ability to muster up the time and energy to be a good and effective DPL for the full length of the term.

When in California last year I visited the NoiseBridge [1] Hackerspace. I was very impressed with what I saw, good equipment and very friendly people. The general concept of a HackerSpace is that it is an environment to support random creative projects. The first picture is a sign near the door which is clearly visible to anyone who is leaving, it encourages people to be AWESOME and EXCELLENT by cleaning up after themselves (and maybe others). I think that this demonstrates the core of what is needed to get such a community project going. Generosity towards others was on display everywhere, there was some free fruit on a table as well as a bottle of Port for anyone to drink. Someone had written a note saying that it s not an insecure Port (a computer security joke). Someone had created an artwork that resembled an advert which some idiots had mistaken for a terrorist bomb (the creature displaying the Impudent Finger). The main (only?) phone in NoiseBridge is apparently a VOIP phone, it is located next to an old pay-phone along with some Magnetix and other toys that can be used by curious people of any age. Magnetix have had repeated safety problems that caused recalls so maybe such things are best placed in an 18+ environment. When I visited about 10 people were working on electronics projects. There were a number of soldering irons in use and some serious test equipment (including a couple of CROs) was available. The people doing the soldering were eager to teach other people about their work. Other equipment that was available included some serious industrial sewing machines and some drill presses. A lot of that equipment is unreasonably expensive to buy for personal use and is also rather bulky to store, having it available in a central location is a great service for the community. Finally Noisebridge has a lot of space. There are rooms that could be used for giving small lectures and couches in the central area for people to relax and have impromptu meetings. Of course they had wireless net access too. Australian Hacker Spaces Kylie Willison has written about the Adelaide Hackerspace which sounds promising [2]. The Connected Community Hackerspace is a new one in Melbourne [3]. It operates out of the homes of members so it s not nearly as big as Noisebridge (which has a substantial property rented for 24*7 operation). I hope that we can get something running permanently in the Melbourne city area in the near future. The Noisebridge membership dues are $80 per month (or $40 for starving hackers). I would pay that for a comfortable chair in a convenient city location with net access surrounded by cool people!

• [1] https://www.noisebridge.net/wiki/Noisebridge
• [2] http://kyliewillison.blogspot.com/2010/03/adelaide-hackerspace.html
• [3] http://groups.google.com/group/connected-community-hackerspace

The federated authentication bar BOF will be held tonight at 9 PM US Pacific time in the Manhattan room at the IETF 77 meeting.. Here is information for participation. Reading List

• Use case/briefing paper
• EAP GSS-API Mechanism draft
• RADIUS SAML attributes draft
• sstc-saml-binding-aaa-draft-00
• sstc-saml-eapgss-sso-draft-00
• Feasibility analysis of the approach
• Brief overview

Remote Participation

• Join our audio stream during the session
• Join our jabber chat room at moonshot@conference.jabber.postel.org

Join our mailing list

Note: This post written March 13, and posted after our return. Yesterday was a day of travel. We said goodbye to Jacob and Oliver in the morning. We had thought a lot about how to tell Jacob what was happening and when to tell him. Ultimately, he doesn t really understand time or distance very well yet, and we know that he worries about the unknown. So although he knew about the visit to Indiana for awhile, he didn t know that Terah and I would be going somewhere until th emorning. He wasn t pleased, but seemed to take it well. We told him that we re going to a hotel in Germany and reminded him of other times we ve gone to a hotel. I also reminded him that sometimes a babysitter comes to our house while Terah and I go somewhere else, but we always come back later. That seemed to help. We got to the Indianapolis International Airport in plenty of time for our flight. They have built a completely new terminal building; the old one we were familiar with is now abandoned. The new building is beautiful, sunny, open, and even inspiring. I was impressed. Newark Liberty International, on the other hand, had all the ambiance of a Greyhound station across from the county jail. It reminded me a lot of Chicago Midway, which I used to go through regularly: dark, a bit run down (water stains on the ceilings), and nowhere near enough seating in the gate areas. We wound up standing for an hour before our flight left (late). The food court in Concourse C was something special. As we were witting there, Terah remarked on the constant stream of passengers that walked up to the food court, glanced around, and made a look of THESE are my choices? Which was our exact reaction a few minutes before. Yep, it s the first food court I ve been in where McDonald s was the upscale choice. The sit-down Mexican Cafe had hamburgers with mexi-fries as its main attractions. Terah tried out the dodgy pizza place while I tried out the even more dodgy Chinese/sushi place (I was not silly enough to try sushi there). Ultimately we decided that perhaps the point of the food court was to make us eager for airplane food. The choices in Indianapolis sure put that to shame: TGI Fridays was a real gourmet option compared to the choices in Newark. I was really a bit embarrassed; Newark is a major international airport, and many visitors to the United States will be greeted by a foul-smelling food court and a dingy airport. Yay for being welcoming? Well, really we had a good day of travel and I shouldn t be ragging on the Newark airport so much, so I ll say something positive: there s a pharmacy right behind the food court, which is probably a very convenient location to meet the needs of many diners. Anyhow, our flight left Newark about an hour late, at about 7PM Eastern. As I write this, it s about 7:30 CET (1AM Eastern) and our plane will be on the ground in about an hour. I m excited for the coming week! I got some sleep on the plane, but not a lot. I m hoping that I will have the energy for a good weekend.

Maintaining stable life with unstable distro? This post may sound ludicrous to some of you but please hear me out. I ve been on Debian unstable/Sid for awhile now and it was all cool until yesterday. Besides my work on Debian DebConf/some devel, I m university student, also I do web devel which is my primary source of income, besides all those I try to go out on weekends and have some kind of social life. Somehow I manage to do all these things and I d say I manage them pretty successfully too. Now I m hardcore to the bone, but this is just too much, last week started working on immense web devel project didn t sleep more then 2hrs/day whole week; I also didn t shut down my notebook and just kept it on suspend as I usually do. Either way I was about to print/scan something and I connect my printer and what happens? My whole system freezes, now I ll let you figure out the result of doing hard reset and having a lot of gedit docs open at that time. And yes, I did had that bug reported awhile ago, can t find it now, but it was fixed, seems like it s back again. In the end I m left with weekend completing the lost work + late school work + eclipse 3.5.2-2 ought to be uploaded. I do almost all the work (didn t upload eclipse) and literally pass out on Sunday. Wake up sometime on Monday, wasn t able to get up from bed. Plan: Change my base distro, keep Sid as dualboot or virtual machine
Now, for my time of being Sid user this isn t the first time something like this happened, and by this I mean unexpected/unprovoked bugs. I might not be as hardcore as I used to be, or it s just that I don t have time anymore. So my plan is to get Stable or even Ubuntu for my work/study platform, while I d have dual boot or virtual machine of Debian Unstable/Sid. I m sure I can t be the only one who s doing this, so please give me your advice on this one.

1. Main question is dualboot or virtual machine? Reason I d like it to be a virtual machine instead of dual boot is that my notebook HDD is 64GB SSD (Lenovo X300). By todays standards 64GB is quite small, while the price of SSD is quite opposite of small. So I d like to use this only for my main/base OS, nothing else. Since I use external HDD s having it virtual it s more convenient for me to carry around my image/s. Other day I ordered 4GB of RAM so I shouldn t have problems with performance of this virtual machine. Or even with that much RAM, devel on virtual machine is just not possible? 2. In case I go for Ubuntu, and decide to start packaging for Ubuntu as well, what s the best way to have my work/packages synced within both Debian and Ubuntu (sshfs?). 3. How do I take my PGP keys with me? If I just copy .gnupg and .ssh will that be enough? 4. Can I have same keys both on my host machine and virtual machine at the same time? 5. Some other idea of sticking with Sid?

Input to any of these questions/other suggestions would be greatly appreciated.

Today is March 24th, that means Ada Lovelace Day, and it is being pushed as an international day of blogging to celebrate the achievements of women in technology and science. The aim of Ada Lovelace Day is to focus on building female role models not just for girls and young women but also for those of us in tech who would like to feel that we are not alone in our endeavours. There are some very good examples of women that have been important in the development of science and technology, starting with Ada Lovelace herself (the first developer of an algorithm intended to be processed by a machine), Rear Admiral Grace Murray Hopper (developer of the first compiler for a computer programming language), Adele Goldstine (who wrote the complete technical description for the first digital computer, ENIAC), as well as the six women who did most of the programming of if (Kay McNulty, Betty Jennings, Betty Snyder, Marlyn Wescoff, Fran Bilas and Ruth Lichterman), or women scientists, or women inventors, etc. Well, I m not going to write about any of those, even when any of them would surely deserve that and more for sure. I m going to write about a woman who has definitely been very inspiring and supportive for me when I was starting to get in touch with Free Software and Debian, and who is probably the most important single reason I decided to go for it. It is definitely hard to write about someone you admire when she happens to be one of your best friends, and in fact I m pretty sure that most of the people reading this article already know her, so there s no great mistery. I m talking about Amaya Rodrigo, the first european female Debian Developer (AFAIK) and co-founder of the Debian Women project, and also member of Hispalinux Board in the golden days. The first time I met her she was giving a talk in Madrid about a project that was starting then, Debian Women, and it was very inspiring for me. Inspiring enough for me to join the project. Afterwards I ve learnt more about her, how she overcame many dificulties, like starting to work with computers quite late, among others. The real merit of a pioneer is not really to be the best techie out there, but to overcome the difficulties and doing it the best you can, when no one else has done it before. I m not going to write her biography here, it s not really the purpose of this blog entry, and you probably can ask herself directly. This blog entry is, as I said at the beginning, to highlight women in technology that I consider inspiring and relevant. You know, I admire you, Amaya

I'm now on my way back from The first miniDebCamp and miniDebconf that happened from March 13th to March 19th in Khon Kaen, Thailand. This even was organized locally by a team of very motivated Thai Debian enthusiasts and contributors, such as Theppitak Karoonboonyanan (*the* Thai DD), Neutron Soutmun, Kitt Tientanopajai, and all those whose name I'm not remembering as of now (I hope they won't mind). The even had kinda the structure of DebConfs, with a few days of "Debcamp" to begin. See the full schedule. We were hosted in Khon Kaen University (KKU), one one the most famous universities in Thailand, a small "town in town" in a city with a few hundred thousand inhabitants (dunno exactly). Lodging was done in a hotel located inside the university. Interestingly, the hotel was also hosting youg students participating to "Summer Camps" (apparently training systems to get good school results) gving to all this a very young atmosphere. The hacking lab and talks location was a 30-seat room in the university library, and meals were brought in there very efficiently, with the very specific way that Thai people have to transport each and every kind of meal (in small plastic bags closed by rubber). I arrived only in the 3rd day because I had commitments at home that made it impossible to me to come for the first day. During these days, people have been very busy hacking and participating to the Bug Squashing Party. During that BSP, about 50 bugs have been touched, without about 15 or so closed. Other non Thai attendees were Andrew Lee from TW, Paul Wise from AU, Daiki Ueno and Yukiharu Yabuki from JP. Organizers were expecting some attendees from neighbouring countries such as Laos, Vietnam or Cambodia. Unfortunately, none of them could come, including Anousak Soupavanh, leader of Lao free software localization efforts, who I was very impatient to meet. Transport difficulties, or visa problems, do not make things easy in that part of the world. On Wednesday we had a "DayTrip" as it is common for such event. We went abotu 50 km away from Khon Kaen, to visit a nice place, close to a dam lake, and climbed a hill surrounded by a big temple and a giant Buddha statue. Then we had a wonderful lunch in a fish restaurant in the very specific Thai way to share stuff: everything is on the table and you pick your food here and there, at you rconvenience. Of course, local advice before trying apparently innocent food is always worth it because the fire might be hidden anywhere (for instance in that soja plate which I tried and that set my mouth as a burning hell for 20 minutes). The journey ended by a visit of a great temple in Khon Kaen and, very noticeably by a dinner in a very popular barbecue restaurant in "all you can eat" style for...100Bath (so, about 2.5 euros). Maybe only vegetarian people had more trouble enjoying the meal as it was mostly made of various meat (and sea food). The talk days were very intense, at least in my opinion. Probably because I ended up giving four talks, some of them completely improvised (about IP-over-DNS, which I was using at the hotel and about which many wanted to learn a little bit more, and GPG keysigning processes). It turned out that the GPG talk was well received and, discussing with Paul later on, we agreed that such a talk, mostly meant to explain the DOs and DON'Ts For good GPG keys signing, could be a good idea even for Debconfs. There were also a few talks about local initiatives and efforts to develop (and not only promote) free software. We have no recordings of these talks as we were infortunately missing some video recording installation (maybe next time, Thep) just like the miniConf that was happening in Panama at about the same time was having. Due to local regulation on the university network, we had some limitations with Internet access (some firewalling that for instance was preventing SIP to work properly, which made a video-conference with a japanese user group fail, unfurtunately). The event ended in a round table discussion about ideas to organize something bigger in the future. The local community in Thailand has apparently the energy, maybe ressources and local support to be able to organize a slightly bigger event as first try (somethign like an Asian DebConf or something similar, targeting mostly Asian contributors and about 50-100 people. Thailand seems to be a good target to host such event, with many things being relatively inexpensive (and not only beer!). And they even think about possibly hosting a Debconf at some time in the future (actually, Martin Krafft should also be credited for bringing this idea). That isn't as crazy as it seems and, provided that potential organizers start involving themselves in the current Debconfs, everything seems to be possible. After all, if we look back to 2005, only one person (hello, Safir) was seriously thinking that Debconf could really happen in Bosnia and Herzegovina, right? After this week (followed by 2.5 days of sightseeing in Bangkok for me, plus a small meeting today with local Thai Linux corporate users and IT company owners), I feel like the mood in Asia about Debian development is high and full of potential. The miniconf last year in Taiwan was already a good success, by establishing a good connection between people.....we need to keep that alive and, hopefully, there will be other miniconfs in this part of the world. And, well, if I can be there, I'll be there.

Dear New Yorkers, I'm going to speak at Free Culture NYU about my current project, OpenHatch. Please come out! To get there:

• 8 PM, Monday 3/22
• Kimmel 904 at NYU (map)
• More info

If you need help finding the place, call my cell phone. (Visit the freeculture.org contact page for that.)

GNU Hackers meetups are a face to face meeting to balance the online collaboration that GNU maintainers and contributors do all the time. These are a recent (since 2007) thing, and are having a positive effect within GNU and the FSF. The LibrePlanet 2010 GNU Hackers meetup runs concurrent with the first day of LibrePlanet. We started with some project updates:

• SipWitch a project to do discovery of SIP endpoints and setup encryption etc. This looks quite interesting, and is looking for contributors.
• Bazaar I presented an update on where Bazaar is at and what we re focusing on now and in the future:
  • short term: merging and collaboration:
    • merge behaviour
    • conflict behaviour
    • develop a rebase that can combine unrelated branches
    • looms to be polished, or pipelines extended something to manage long-standing patches for distributions, or other environments that need long lived patch sets.
  • long term
    • continuing optimisation of network and local perf
    • meta-branch operations mirror collections of branches,
    • work with many branches at once (many branches in one dir (a-la git, hopefully less confusing)
    • easier get up and go for new contributors
  • now and forever
    • keep fostering community growth
    • we re aiming for negative bug growth- get on top and stay there

Felipe Sanches presented his list of things that should be on the high priority project list:

• accessibility since 1st boot
• reconfigurable hardware development (FPGA tools) this is particularly relevant for handling e.g. wifi cards that have a FPGA in the card, so we can replace the non-free microcode.
• nonfree firmware issue

lunch John Eaton on Octave. John compared the octave contributors 30 or so over the years, and never more than 2 at a time. The Proprietary product Matlab that Octave is very similar to has 2000 staff working at the company producing it. Users seem to expect the two products to be equivalent, and are disappointed that Octave is less capable, and that the community is not as able to do the sort of support that a commercial organisation might have done. Octave would like to gain some more developers and be able to educe users more effectively convert more to become developers. Rob Myers, the chief GNU webmaster gave a description of his role: The webmasters deal with adding new content, dealing with mail to webmaster@, which can be queries for the GNU project, random questions about CDs, and an endless flood of spam. The webmasters project is run as a free software project the site is in CVS (yes CVS), visible on Savannah. Templates could be made nicer and perhaps move to a CMS. Aubrey Jaffer on cross platform. There is a thing called Water which is meant to replace all the different languages used in web apps generates html, css, alters the DOM, does what you d do with javascript. So there is a Water -> backend translator that outputs Java for servers, C# for windows, and so on. (I think, this wasn t entirely clear). He went on to talk about many of the internals of a thing called Schlep which is used as a compiler to get scheme code running in C/C#/Java so as to make it available to Water backends in different environments. Matt Lee spoke about GNU FM GNU FM is a free last.fm site. The site is running at http://libre.fm/. 24ish devs, but stalle after 6 months whats next? Matt has started GNU Social to build a communication framework for GNU projects to talk to each other e.g. for each GNU FM site to communicate on the back end, with a particular focus on doing social functionality groups, friendships, personal info. The wiki page needs ideas! GNU advisory board discussion too much to capture, but focused GNU wide issues things like how projects get contributors, contributions, coordination. Teams were a big discussion point, bug trackers how to coordinate teams followed up of that, and there is s GNU Source Release Collection project to do coordinated releases of GNU software that are all known to work together.