Is It Documented?

For free software projects, documentation is key.

If software builds, runs and works, others still may not be able to use it until proper documentation is available. Upstream documentation isn't always complete or easy to understand, so often additional user documentation is required. If manual steps are required, they should be documented clearly and correctly. The documentation option of choice is the Funtoo wiki as well as man pages.

For source code, verbose comments should be used. You may be working on the code now, but someone else might be working on it six months from now. Developers are expected to write clear comments that are sufficiently non-technical and provide the necessary context to allow less experienced developers to understand critical parts of code, and ideally all parts of the code. Please see Coding Standards.

Is It Well-Designed?

Optimized?

Maintainable?

It builds and runs, and I can use it to perform real work. But is the system well-designed? Does it work reliably? Are all available patches and fixes in place to ensure a reliable computing experience? Is Funtoo Linux providing the best technology possible to users? And is this technology easy to maintain? Remember, all things being equal, less code is better than more code because it is easier to maintain. Are there verbose comments in code where necessary?

Are We Getting Better?

OK, we're doing all of the above steps. Here is the next test - are we getting better? Is the quality, security, usability and maintainability of the distribution improving over time, or is it going up, and then going down, and we're not really making any forward progress? The ultimate goal at the end of the day is to make forward progress in the quality of the distribution. This requires better automation, better tools, better processes, and investment in research and development and new ways of doing things. It also requires the right attitude. If we are doing a lot of work and the overall quality of the distribution is not improving, then our efforts are not making a long-term difference, even though they may be addressing immediate bugs and issues. We must ensure that our efforts are worthwhile, and they are making a positive long-term difference in the quality of the distribution.

What is The Real Problem?

Building on this theme - when a bug is encountered, what is the real problem, or root cause? Strategic thinking as well as in-depth troubleshooting is required to identify the root cause of a problem. Should we just fix root causes? No, this is impractical, because doing this takes a lot of time. Instead, workarounds are often used to quickly restore quality to acceptable levels. However, just implementing workarounds is dangerous, because bugs tend to multiply while the underlying issue goes unresolved. The proper solution is to implement workarounds but to not lose focus on the need to address the underlying issues, or root causes, of the problem. In fact, much of the focus of Funtoo Linux is on this last step - aggressively fixing a bunch of immediate issues so we can start to address the deeper problems once and for all...

Architecture

...and addressing root causes of problems often requires a significant change in software architecture. Funtoo Linux is a project that is not afraid of making significant, even aggressive, architectural changes in order to fix problems. This is what our users expect us to do, and as long as these changes are properly tested, managed, planned, automated and communicated to users, they will not get upset. As stated in the previous paragraph, the Funtoo Linux project is zealous about addressing these core architectural issues -- but we need to get a handle on the more fundamental challenges first. Once workarounds are in place, we'll take a stab at some core system change that will pay dividends well into the future.

Examples

Below, you will find examples of existing efforts that have aligned with these goals. This section will give you a feel for how real projects can be started that align with the Funtoo Linux vision defined above.

Boot-Update

Boot-Update was designed by Daniel Robbins to provide a more elegant way to configure boot loaders under Funtoo Linux. This project was prioritized for several reasons. For one, it had to do with the initial installation experience (see #Does it Run?) Also, lack of GRUB2 support, as well as GPT/GUID support, was identified as a critical weakness in current Gentoo Linux functionality (see #Is it Well-Designed?) Because of this, a new unified configurator was written which uses /etc/boot.conf as the global boot loader configuration file. This represented a change in boot loader architecture (see #Architecture) under Funtoo Linux, in order to improve usability and flexibilty over existing solutions, and to attempt to reduce or eliminate a class of problems related to boot loader configuration, which is especially troublesome with GRUB2.

Metro

Metro was designed by Daniel Robbins and is used to address the "#Does It Build?" question. The existing solution, catalyst, was difficult to maintain (see #Is It Well-Designed?), so Metro was developed to provide a new mechanism for building OS releases.

Forked Ebuilds

Not all improvements involve large software development efforts. In fact, the majority of fixes involve relatively small fixes to ebuilds. These fixes are often made to fix a Metro build failure (see #Does it Build?) or address some quality issue (see #Is It Well-Designed?). The www-servers/nginx ebuild was improved to provide better default settings for production systems, with corresponding changes made to sys-libs/pam to allow this to work. dev-lang/python contains fixes to ensure that Metro builds complete properly and a valid /usr/bin/python symlink always exists.

OpenVZ

OpenVZ support is a specific priority of Funtoo Linux. Funtoo Linux maintains a patched sys-cluster/vzctl with various patches to fix a variety of problems. In addition, openvz-rhel6-stable and openvz-rhel5-stable ebuilds have been created to ease installation of production-quality OpenVZ kernels (see #Can I Use It?) In addition, OpenVZ documentation exists on the wiki (see #Can I Use It?)