posted by Eugenia Loli on Mon 28th Apr 2003 15:48 UTC

"Bug resolution, team work, graphical installer"
6. Which are the hardest parts during the resolution of the architectural or coding bugs in the 5.x branch? How many people are working in the 5.x branch these days?

GNOME under the stable FreeBSD 4.8 Scott Long: The hardest problems have come from mediating two solutions to the same problem that take competing directions. We formed a Technical Review Board last fall that is chartered to resolve these kinds of disputes and help set future technical direction. Luckily, these problems rarely happen, and the issues they bring up are valuable and help us grow.

Wes Peters: Keeping all the various development projects moving and from bumping into each other. This is no different than any other software engineering project involving hundreds of developers all over the globe. In point of fact, it's quite a bit easier than any of my experiences with similar size development teams in the commercial world.

I believe this is because everyone in FreeBSD wants to be there, and wants the system to grow and succeed by our standards, rather than being there just because it pays the bills, but don't have proof of this.

Since FreeBSD 5 is such a new system in many ways, everyone who wasn't intimately involved in the underlying changes comes to 5.x as a mostly new system. We try to ameliorate this with documentation on the new and changed APIs; the documentation group is one of our big strengths.

Greg 'groggy' Lehey: Resolution of bugs is seldom an issue. A bigger one is the question of direction. In open source projects, there's a tendency for the person with the greatest amount of drive or spare time to get to choose the solution. It may not be the best solution, but others don't have the time or energy to fight to get their version accepted. This is one of the backgrounds for our Technical Review Board, which should help stabilize the direction of the project.

M. Warner Losh : Actually, I'd say that the hardest parts of getting things right is more getting the progammers to play nice together. I sit on both the trb and on the core team. Often times technical disputes are really personality conflicts using the technical issues as proxies. Typically they reach a fairly advanced state of dysfunction before the core team is brought into the loop, and it takes a lot of time and effort to resolve the issues. I've spent 20x the time on the "play nice" aspects of the project than I have on the technical aspects. Usually after individuals start to play nice, they resolve the technical problems. I know of only one case where the trb had to get in the middle of a dispute and actively work on a solution that both parties could agree on. All the other times people were able to work it out, or the role of the TRB was to pick A or B as being better. In contrast, the core team has mediated something like 10 or 15 developer disputes in the past year.

Greg 'groggy' Lehey: We don't distinguish between people who work on the 5.x branch and other parts of the src tree. We've seen 152 different people commit code to the src tree in the last 12 months, 102 in the last 3 months, 63 in the last month, and 13 in the last two days.

7. Are there any plans on offering a graphical installer for FreeBSD and maybe some graphical or Curses-driven front-ends for most of the main services (e.g. for NAT, dhcp, firewalling etc)?

Scott Long: The 'libh' project was meant to provide a modern replacement to the venerable 'sysinstall', but work on it seems to be stalled. There has been talk over the years of different FreeBSD vendors and resellers stepping into this area, but nothing yet has happened publically.

Wes Peters: This is an issue that always generates a lot of discussion but little code. There is a long-running project aimed at creating the underpinnings for an entirely new installer, in the form of a library of code that handles the really hard parts of doing things like updating system configuration files in a way that can be islotated to a single installation, and backed out. We anticipate that as this project matures it will grow into an actual installer program, but don't have a timeline on such a development.

I don't know of any currently running projects to develop a graphical installer along the lines of what RedHat or Mandrake have for Linux. Nobody who wants one badly enough and has the skills to do so has materialized yet. Its not completely clear that such an installer is critical to the ongoing success of FreeBSD either; we are asked more often for installers that can be run remotely over a network, or over a serial console.

Greg 'groggy' Lehey: There have been various plans, but none have been overly successful. Currently people are enhancing sysinstall (which is curses-based) to perform some of these functions.

I also investigated such tools in some detail while updating "The Complete FreeBSD". I came to the conclusion that such tools are frequently counterproductive. They give people the impression of control when in fact they're frequently just capable of updating files without understanding the effects. This is particularly the case with firewalling. If people can't read a configuration file and use an editor, why should they be more successful with less powerful tools? Yes, lots of people ask for this kind of tool, but I'm reminded of the punch line "It's just what I asked for, but not what I want".

Table of contents
  1. "Intro, Java, Corporate Support"
  2. "Linux, the desktop market"
  3. "Maturity of 5.x branch, speed of development compared to Linux"
  4. "How FreeBSD compares to other Unices"
  5. "Bug resolution, team work, graphical installer"
  6. "Optimizations, SPARC/PPC/Itanium/Opteron ports, third party tools"
  7. "XFree86 issue, re-unification of the BSDs, UFS2"
  8. "The SCO questionmark"
e p (0)    94 Comment(s)

Technology White Papers

See More