Project Mission And Values

[jperkin]

Why Values Are Important

At the start of a new project it is important to lay down what the primary mission for the project is, and what core values help propel us in unison towards it.

Values are important. Bryan Cantrill has an excellent talk, Platform as a Reflection of Values, that really helps to explain how values shape a project, and provides some of the reasons why conflict arises when those values are not shared.

This project was started due to a conflict of values. As someone looking into the dreckly project, the following mission and values should help you decide whether this might be a useful project to you, and one you may (or may not!) want to get involved in.

Mission

Our mission is: To provide a useful collection of software for all UNIX-like systems.

Our mission differs from pkgsrc, which historically had similar ideals, but over time softened the "all" to only supporting modern releases, and only prioritising NetBSD in the testing of changes, leaving non-NetBSD support to deteriorate.

dreckly aims to support all systems, all the way from HP/UX on PA-RISC, through MacOS X Tiger on PPC, to the latest NetBSD/Linux/macOS/illumos/etc on x86_64 and arm64, and even Cygwin!

A key word in the mission that might be overlooked is useful. Anyone could check out an older copy of pkgsrc, from a time when some of those systems were still supported and build packages (which is the argument used for dropping support in newer pkgsrc), but that software would be quite out of date. While software does not decay, other surrounding factors such as changing protocols or newer SSL certificates do mean that a static archive ends up being less useful over time.

We aim to provide useful, up-to-date versions of the software that we package, for all systems.

Values

Just because there are values missing from our list, it does not mean that they are unimportant! Of course we want the latest software, and of course we want dreckly to be fast, secure, resilient, approachable, and many more. However, these are the core values that help us in times of decision to choose a path forwards, and help to avoid conflict and frustration.

Portability

Obvious, perhaps, but still needs to be stated. What does this mean in practise? For example, some projects are being rewritten in Rust. If the software in question is a dependency for other non-Rust software it means we need to maintain the last non-Rust version and provide infrastructure so that it will be used on platforms that do not support Rust.

A focus on portability means additional work, but ultimately provides larger benefits. For example, even if a platform supports Rust, it may be expedient to use the non-Rust version, and the work benefits everyone.

A value of portability does not just extend to packages. We would like to see renewed efforts to provide alternative pkgformat backends. Not only would this provide packages in native packaging formats, it would help to improve the quality of the default (and currently only) pkg backend.

Portable software is well-engineered software.

Stability

Dreckly rejects the "development phase" approach, where the tree is unstable for a period of time before a freeze phase when bugs are then resolved. At no point should the tree be unstable. Every change must improve the status quo. It must be possible to cut a release at any point, with the expectation that each successive release is better than the last, for everyone.

Larger bodies of work such as new infrastructure features or major changes to important packages must be developed on branches before being merged atomically once they have been proven to cause no regressions.

Robustness

"Hey it compiles! Ship it!" is not good enough. Packages must build regardless of what software is installed on the system. Test suites should be clean. Post-install checks must be enabled and correct. If a build option is provided it must work. Binary packages must not be reliant on anything from the build host.

We must do everything we can to avoid both build-time and run-time failures.

Maintainability

Packaging software can be difficult. Sometimes a large number of patches and changes are required. People come and go. At no point should any package become impenetrable. It should be possible for anyone who is familiar with packaging concepts to be able to make modifications as easily as possible, or to get started creating a new package. If custom bootstraps or whatever are required then every step required to generate them should be implemented. If a common pattern is used in multiple packages then we should consider creating infrastructure to provide a generic solution.

Sometimes it can be tempting to modify upstream software to suit a particular requirement. This can create additional maintenance headaches for future updates, as well as confuse users who may be used to the standard behaviour. Significant thought and consideration must be taken to question whether any such changes are worth it.

When adding options to a package, consider strongly whether they are necessary, as non-standard options almost always end up broken.