1. Has the Fink project considered adding the FinkCommander as part of the whole project, for easier usage by the Mac OS X users?
Max Horn: For the upcoming Fink release, 0.5.2, we plan to include FinkCommander as part of the binary installer disk image. We also want to mention it in some more spots of our docs. However, it still is and probably always will be, a separate product. We work together with its author whenever needed, but there are no plans to make it part of the Fink project itself.
2. Is the Fink Project working together with Apple in order to guarantee better compatibility of its ported X applications to the Apple X11 server (which is currently in beta)?
Max Horn: You really should be asking: Is Apple working together with us? :-)
They are the big ones, and they choose whether they want to ignore us or work with us. Luckily, the answer is (at least to a degree) yes. There are numerous Apple employees on the Fink mailing lists, and in fact two of our project members work for Apple (although their involvement with Fink is a purely private thing and not in any way endorsed by Apple). For example there was one serious bug in Apple X11 beta 1 which caused (not only us) lots of headaches, and this was resolved in collaboration: Apple employee's discussed the problem with us on fink-devel (our fink developer mailing list), and fixed it. And in the meantime we implemented a workaround as part of our system-xfree86 package with their help (to bridge the time till beta 2 was released).
Overall, the mood at Apple seems to be friendly towards Fink, they refer to us in various places of their homepage, for example.
3. Please tell us about the team that consists Fink. How many members are there, how many maintainers and also, do you have a kind of quality control to ensure that the ported apps work as they supposed to?
Max Horn: We currently have three project leads (Benjamin Reed, David R. Morrison, and me). The SF.net project currently lists 31 members, but that number is pretty irrelevant. Roughly half of them are actively working on the project. By my last count, there are about 130 different package maintainers. 23 of those maintain 10 or more packages, and 4 maintain more than 100 packages. Benjamin Reed hold the record with 185 - but many of those are semi-automatically generated language packages for KDE (luckily!).
Which already gives a hint at the second part of your question: Obviously, providing quality control for over 2000 packages is a tough thing. For each package its maintainer is the primary responsible person. If you maintain more than 100 (or, for that matter, more than 30 :-) packages, that's a burden. I believe we need to reduce the number of packages per maintainer on the long run. We are working on this.
For QA we adopted a system somewhat similar to that employed by debian. The first line of defense is the fink package validator which scans an .info file and the resulting .deb files for certain typical problems. New packages (or new versions of old packages) first go to the unstable-CVS tree. There, we mostly relay on feedback by users on these packages (both positive and negative feedback). After some time, if no problems are found, but sufficiently enough people have reported good success, the package may be moved to the stable-CVS tree. Finally, when it comes to the time when we make a new binary distribution, the stable tree is once more combed for any problem with packages in it, before we release this to the general public.
For all this we make heavy use of our bug tracker. If your or anybody thinks (s)he has found a bug in Fink or one of its packages, I strongly encourage that you report it there, we are trying hard to fix things.
- "Fink Interview, Part I"
- "Fink Interview, Part II"