I'm speaking today with the three developers from the HaikuPorts project (formally known as BePorts), and they are Brecht Machiels, Andreas Faerber, and Scott McCreary. The three have been working on the project for varying lengths of time; Brecht started it July, 2007, Andreas joined it late February, 2008, and Scott recently joined as of April, 2008.

From their website:
"HaikuPorts is a centralized collection of software ported to the BeOS platform. Each port contains the BeOS-specific patches to the original source code. Along with a Subversion repository to store all patches, this Trac site eases cooperation on porting efforts. There is also a mailing list for the discussion of the project. The BePorter tool is provided to ease the fetching, patching and building of source code."

HaikuPorts is now the formal name of the project, and consists of many different sources of applications; some from GNU (Savannah), some from SourceForge, some from elsewhere. As the name change was fairly recent, please forgive any references to the older BePorts moniker.

They've kindly allowed me to ask them some questions, taking time out of their busy schedule to do so and enlighten us all with their answers.

So, on with the questions!


Brecht, you began this project in late 2007, is that correct? What sort of vision did you have back then before you started it? What inspired you?

Brecht:
I'm a relatively new to the BeOS/Haiku community. I used to be a dedicated AmigaOS user, but the lack of professionalism of the IP holders and the continuous fighting in the ever-shrinking community has made me look for alternatives. With the Linux desktop not being able to convince me, I decided to try out BeOS and was impressed with this lean and efficient OS. However, BeOS seemed pretty much dead at that moment and I mostly ran Windows. Later, not liking where Microsoft was taking Windows (Vista), and encouraged by the progress the Haiku project was making, I decided to give BeOS another try.

One day in July 2007, I found myself trying to port an application (I think it was Subversion) to BeOS. Looking for previous ports of Subversion and its dependencies, I found that there exists a lot of knowledge on porting applications to BeOS. Unfortunately, this knowledge is scattered all over the net -- if it was recorded in the first place -- and often hard to find. So, I thought it might be interesting to put together a website where developers could document and coordinate porting efforts. Hence, HaikuPorts was born.

Not much later, real life took over and HaikuPorts was idling. Andreas started a discussion on the Haiku developer mailing list about coordinating porting efforts and he was pointed to HaikuPorts. Adreas and Scott joined HaikuPorts and got the ball rolling again.


Let's take an average day in the life of a HaikuPorts Developer; Outline for me what one goes through, what tasks are necessary to keep things smooth, and keep the project progressing forward?

Scott:
For me it's, to research prior porting work, download newest source code packages, attempt to compile, report results, rinse, repeat

One of the side effects of this project is that we are uncovering bugs in Haiku, reporting those, and getting them resolved, case in point:
http://dev.haiku-os.org/ticket/2130

With Haiku now able to build things natively we've decided to change the main focus of HaikuPorts, to be more focused on Haiku.

Andreas:
I guess I can speak for the three of us that we all work on this in our spare time, so an average day in our life has little to do with HaikuPorts.

Porting usually does not require much time by itself, most time is spent running configure scripts and compiling, which often can run unattended while working on something else. The actual porting I would characterize as half knowledge-base, half creative. For some ports, working through a small checklist is enough and doesn't require much programming knowledge.

In its current state, it's still possible to keep an overview of where virtually all the ports stand; so monitoring the Haiku commits and bug reports is part of the game, revisiting certain ports once a relevant change has been made in Haiku.

As for team play, monitoring Wiki changes and reading our mailing list are essentials. The choice of adhering to the naming conventions of Gentoo Portage helps avoid duplicating efforts, since we know exactly where to document our results or to look for previous info.

For starting a new port, a typical workflow might be:
* Setup a new Wiki page for the port and link it from its category.
* Retrieve the latest stable source code archive from that project's site.
* Try to compile it, if necessary pretending to be BeOS via --build=i586-pc-beos.
* If that fails, retrieve the latest stable or even the latest source code from the project's repository and apply some standard fixes.
* Always document what fails during configuration/compilation and what I did about it, so that other devs understand and can spot bad decisions (or myself, when revisiting it at a later point in time).
* Commit patches to HaikuPorts SVN, even when unfinished, so that others can review them and collaborate on them.
* Once a port compiles, run its test suite to check everything works as expected and document any failures. Investigate.
* Finally, prepare patches to be submitted "upstream" to the project.

In some cases this is pretty straightforward, in other cases it's an iterative process or involves collaborating with the Haiku developers to fix bugs or add features, by filing tickets or supplying patches. The Wiki helps sharing knowledge both about porting issues as well as about relevant OS issues. In that aspect, HaikuPorts offers much more than existing ports systems, such as Gentoo Portage or MacPorts, which mainly supply patches and an automated system to apply and compile them.

As for progressing forward, the project is progressing in two dimensions - more ports are being documented as such, and more ports are being completed in terms of working and passing their test suites. Both require time, therefore we need to focus our efforts on the things we deem most important, which brings us to the next topic:



The Trac task/bug manager you have in place is pretty awesome, do you ever foresee a day when the project will out-grow it and require moving onto a bigger tracking system?

Brecht:
I didn't have much experience with Trac before creating HaikuPorts and I can't foresee if or when the project will out-grow it. I guess we will have to wait and see.

However, the Trac wiki is far from ideal for documenting porting efforts (the so called PortLog). There's too much the developers need to do in order for it to remain consistent. For this reason, I'm currently looking into writing one or more Trac plugins so that this can be done more elegantly.


What is the current status of the project, in terms of project goals and milestones?

Brecht:
I still consider it to be in it's infancy. However, with the increasing interest from the community, I think it can mature quite quickly.

I have initially set up milestone M1. It includes ports of the most common libraries and applications. Recently, Andreas added a new milestone for a self-hosting Haiku. This one is of highest priority.


Are you accepting new developers at this point in time? If so, where is the best place they can apply? If not, why not?

Brecht:
Everyone is welcome. Information on how to join the project is on the website. There's also a mailing list for developers to discuss porting issues and the project itself.

Andreas:
Both Scott and I have already joined the project and, for my part, I'd definitely welcome new contributors. Practically speaking, the less time I need to spend on unrelated documentation, the more time I can spend on my own porting efforts. And the more people porting, the faster the progress, at least in theory.


What has been the most challenging package to port thus far and what made it that so difficult?

Brecht:
A port of Perl to BeOS BONE with the help of flock_server suffers from a weird problem. I have not been able to solve it, but did find a way around it, though not quite a satisfactory one. My adventures have been documented at http://tools.assembla.com/BePorts/wiki/dev-lang/perl

Andreas:
For me, that still is the glib library. It has a seemingly endless tree of dependencies, and while on BeOS I already had it compile once, on Haiku I still haven't reached that point yet and have encountered multiple issues in Haiku on the way.


In regards to BePorter, why have you made it require the GCC based on gnupro-3.4.3 versus GCC 2.95.3? Or is that simply a typo on your wikipage?

Brecht:
Many applications and libraries require a more recent GCC than 2.95.x to build. I'm not fully up to date on the GCC 2.95 versus 3.x issues, but AFAIK that's only a problem for C++ software. C++ software, however, is not that common in UNIX land.

However, as the gnupro-3.4.3 choice is for BeOS and with the change of focus to Haiku, this will change.


Some reports online indicate the entire 3.x branch for GCC is not as stable as GCC 2.x. Have you found this to be the case?

Andreas:
Many Linuces, Mac OS X and Solaris for instance have been using GCC 3.x; some software, like QEMU, even still relies on it for correct operation. On the other hand, apart from BeOS/Haiku I do not know any other system still using GCC 2.x. As in any software, there tend to be bugs or unexpected behavioral changes; I don't think general statements with regard to stability can be made. For Haiku, it is a logical step to take the latest stable gcc, skipping gcc 3.x.


Why did you choose to go with Python for BePorter? Was it your first choice? Is it the ideal choice?

Brecht:
Python was the first choice because it's simply a programming language I like. It's easy to write in and comes with an extensive library of classes.


Have you developed any test utilities that might be of interest to other Python developers?

Andreas:
Not that I'm aware of. Two thirds of the team are currently working exclusively on the ports themselves, which are mostly in C: Personally, I am only using simple shell scripts to avoid recurring command lines, at this stage. Running tests on the ports usually involves running `make check` and reviewing output or log files as a human.


What port are each of you currently focused on, and what factors were involved in deciding to port it before anything else?

Andreas:

For me, that's Mono. I have come to like the idea of the Common Language Infrastructure, that is compiling the language of your choice to a common binary format and being able to share classes between languages. Mono currently seems the best CLI implementation in the non-Windows world to me, and I've occasionally contributed to the project. But like most ports, working on it has a tree of dependencies, including GNU autotools, glib and Subversion, so this goal has pretty much influenced all the other ports I've done so far.

Scott:
This week I'm attempting Cmake, 7zip and Lua. One of the factors you'll quickly find is that when you attempt to port app X, you find out that you need to first get app Y and app Z working.


You touched on documentation earlier, and I'd like to dive into that a little, if I may. How tightly do you stick to the guidelines you have developed when creating a new "port"? Looking at the BEPFile structure, I read with interest how it outlines the required syntax and name/value pairs. Do you see documentation and guidelines as the root cause of these requirements or the other way around?

Andreas:
I do not currently see the BepFiles as the essence of HaikuPorts. But overall, documentation is the essence of the project, both in terms of machine-readable patches and human-readable information. The guidelines set out for documenting ports aren't really complete, but they help assure the quality of the project, by providing a consistent structure for users to locate the information they're looking for.

The project is evolving and so are our guidelines. They are not being imposed on others, they have their reasons and we've been open to suggestions on improving them.

BeOS was a stable operating system, so the BePorter tool was a practical aid there. However, when overwriting my Haiku partition with each build, re-downloading and patching sources is obviously not the most efficient way of working; and for getting the respective projects to accept our changes, we need to create different patches from those processed by BePorter, so we have been extending our guidelines to accomodate this. The HaikuPorts mailing list serves as medium for discussing such issues, which btw anyone is free to tune in to.

Brecht:
As Andreas points out, the essence of the project is documentation. The BepFile is also part of this documentation. It includes clear information on the status of a port and on how to build it. This however duplicates some information that should be in the PortLog. In the future, I envision the BepFile to be (partly) generated from the PortLog.


Is there a "Magic List" of software that you'd like to see ported over before Haiku achieves R1 status? Or is it more of a master list that the project will eventually achieve?

Andreas:
There is a milestone tracking ports involved in Haiku's self-hosting ability, which roughly corresponds to Haiku's R1 Alpha 1 milestone. For instance, this includes porting the latest stable version of Subversion, for being able to checkout the Haiku sources with a Haiku-compiled Subversion instead of depending on old binaries from BeOS.

Scott:
For me, I'd like to see everything listed in the old BeBits LibPak included. That way when Haiku reaches R1 you'll be able to use most of those old programs that relied on those libraries.


Are there non-programming tasks that are required for the project that someone who is new and willing to join the project can perform, or have these been delegated/handled already?

Andreas:
The project is still quite new and not yet widely known, so apart from making software work, things to be done include setting up Wiki pages for new ports, documenting previous porting attempts, maybe creating a logo, adding more non-developer-directed documentation and spreading awareness for people to document their ports at our site. So being a developer is not a strict requirement for contributing. In the end it's all about making software accessible to Haiku users.

Scott:
Most of the preliminary work I think can be done by people who have just some basic programming skills. That is setup a build environment, find packages that need ports and try to build them.


In working with each other on this project, what are the three positive aspects that you've discovered so far about each other that makes it an enjoyable experience?

Brecht:
I think it was very helpful to receive criticism on HaikuPorts from Andreas and Scott. Changes to the project are always first discussed on the mailing list in a constructive way. Each of us is open to comments. That makes cooperating very enjoyable.

Andreas:
We're from three different countries, with three different perspectives on the project that so far seem to fit quite well.

Brecht I see as a visionary who saw a need at a time where few people cared; now with Haiku's progress it turns out very handy to have around. And while not currently being able to spend too much time on porting himself, Brecht has been a mentor to us, with a pretty practical view on things.

Scott is looking at the project from a Haiku view; he has been investigating what ports could help fill in missing functionality of Haiku itself, which I think is very noble of him. That way he is looking into ports that neither Brecht had on his list nor did I think of, that's quite refreshing.

Scott:
I'm new here and am still getting up to speed. Andreas has been pointing me in the right direction when I mess things up ;)


Can you give some advice to programmers new to both Haiku and your porting project, if they wanted to get their feet wet and just dive in?

Andreas:
As for the open source community as a whole, there's at least two ways to get your feet wet - the 'selfish' way of porting a tool because you yourself need it there as a user, or as developer as a runtime for potential users, and the 'altruistic' way of porting something to reach a higher goal for a project, not of immediate benefit to you, be it Haiku OS or a HaikuPorts milestone; but in any case there's also the educational aspect of porting software, learning all kinds of things by diving into it - when things break you learn the most, both about how the software does certain things and about how Haiku works underneath the API. Just don't be afraid of failure, don't hesitate to ask, and start by building your own Haiku image. There's a couple of tips for getting started with porting on Haiku on our Wiki already and we hope to extend it as necessary.

Scott:
If you already know C/C++ then you're most of the way there. Read up on the Haiku project especially the development notes and such. If you want to learn about the API then check out the BeBook/HaikuBook and even Dan Sydow's book all of which you can find online. Subscribe to the Haiku dev mailing list and try out Haiku builds, either in a VM or on real hardware.

Get familiar with how things work and file tickets for things that don't. If you were a former BeOS programmer then dig up your old code and see if it works on Haiku, and if not work on fixing it up so that it does. Chances are that it will just work.


Lastly, and I always throw in at least one of these types of questions just because I can, what one music CD would you take to a deserted island, and why?

Brecht:
I don't think I have one particular favorite album. If I still had time before the boat sank, I would compose a CD with music from artists like Pink Floyd, Fleetwood Mac, Steve Miller band and others. I'd probably throw in some chiptunes too :)

Andreas:
Not really a CD, but I'd take Coldplay's Fix You along. Both for various personal reasons, and the connection to porting software and software development in general should be obvious!

Scott:
Nirvana's Nevermind, I still enjoy listening to that whole CD even after all these years. When I converted it to mp3 and installed it onto my iPod I didn't know about the hidden song, so just when I'm about to take my headphones off since the music stopped like 10 minutes ago here comes one more bonus song.


I want to thank you all for your time and consideration in answering our questions, and I wish you the greatest success on this project! Thank you.

Brecht:
On behalf of our team, I want to thank Haiku News for the interest in HaikuPorts. I'm sure this will help spread the word. I welcome anyone who would like to join the project.

Just a small request today, which I thought I would put out there for anyone with some time to spare.

I was talking with some of the folks in #kvm (on irc.freenode.org) about why Haiku is no longer working as a Guest OS in KVM, how Haiku does not even boot, etc.

They pointed out that it did indeed work on earlier KVM releases, but if we're to figure out why it no longer does, to please submit a bug report to the KVM Development Mailing List and someone will assuredly look at that report.

I ask that we do this, to get the ball rolling again in this respect, and continue to work with the KVM folks on getting their software working with our OS once again. Most likely it'll just take ten minutes, I mean, how hard can it be? :)

*update* And... We're back.

We're upgrading to a newer server that has PHP 5 support, among other things that are required in the long run.

Just wanted to give a headsup that the site may not be accessible for about 24 hours for a few minutes apparently, once the upgrade is initiated, due to DNS propagation. I'll be starting this process this coming Sunday, April 27th, 2008, and the site should be reachable by Monday.

The only real downside to this will be the loss of our Torrent Tracker, as this was provided free-of-charge by our webhost, and with the new server this feature is no longer being offered. As usual, if you have any questions or comments, please feel free to email me.

Cheers,
Chris Simmons