FreeBSD.org - What went wrong; and a way out

Few would disagree that we, as a project, are in a spot of bother. This is a short version of something that I wrote that rwatson told me was too long.

We began, circa 1993, as a pair of organizations. FreeBSD.org handled making a 'damn fine unix' that aimed for technical excellence. Walnut-Creek CDROM took that and made a product out of it and supported it.

Since WC-CDROM has gone, we tricked ourselves into taking on everything. We spread ourselves too thin. It's not for the lack of effort or work. We've come up with some extraordinary aberrations to try and maintain the illusion. One of which is code freezes. We used to freeze because of cvs problems. Then we realized that was a way to force developers to help with releases. Now, there are no scm reasons for it but we maintain it to force people to help re@.

There is something horribly wrong with that picture. We've lost focus on being technically excellent. As a result, we've fallen behind in technical excellence AND our releases and release process is somewhat archaic.

We've become a "Jack of all trades, master of none" project. There is no future in that.

A strawman

If I had a magic wand, or a time machine, and could ignore logistics, hurt feelings and egos and freely change a few key things, here's what I'd do and why.

This means.. no more WIP (work in progress) or half-baked stuff in head. Implementation work is done in feature branches or another appropriate location and they ONLY get merged when they are ready. This is becoming more common, the change is that we complete the process and require it.

The expectation that "head" is functional and stable is vital. I didn't say "release quality" because that implies all the beta testing etc. Any given time should be a reasonable starting point for a release cycle without requiring a freeze, except perhaps to bump accumulated ABI changes etc.

The most destructive things we do to our tree are the mad rush to beat the freezes and the aftermath of it being lifted. We stop that - the code is either ready or it doesn't go in. Period.

This is important because it clearly separates goals and responsibilities. There would be a significant people overlap between them of course.

Think of the Film Industry.. The Director's job is to produce the best film they can. The Producer's job is to make a Product to sell. Both know clearly, unambiguously what they're supposed to be doing. There is a heathly push-pull between the two.

The developer (think director) group's job is to go for technical excellence to feed the downstream release group, along with the likes of PCBSD, pfsense, netapp, juniper, freenas, yahoo, netflix, sandvine, etc, etc.

Once "head" is in a perpetual state of being close to being ready to start a release from, then suddenly the workload for re@ is reduced and they get to focus more on making a release rather than spinning their wheels trying to fix the release.

Right now we suffer from the 100+ person committee problem. Few seem to want to help with releases because "surely somebody else will help". On the other hand if we identify the people with the inclination to do it, and they get to start from a good robust starting point then we've significantly widened the scope of people who can be directly involved.

And for "head" to be reliable and stable need practical, collaborative feature development branches. Potentially destabilizing changes get thrashed out in a feature branch, like what happens in perforce.freebsd.org and people's private and public git trees.

If you look at perforce.freebsd.org, you'll discover that probably 3/4 of the feature branches are abandoned or dead ends because they didn't work out. This is a good thing, working as intended. It is 100000 times better for a feature that doesn't pass muster to bit-rot in a branch rather than to bit-rot in head.

Potentially destabilizing patches get sorted out in feature branches and go in when they're ready. If something can't be quickly trivially fixed that otherwise impairs usability of "head" then head-re-2.0 gets to promptly back it out.

We've got to keep pulling in the same direction. Duplication of work is more easily avoided when people know what's going on and what the progress is. We bump version numbers based on what has successfully reached head, not because of arbitrary release cycle timelines.

Comments, details

TL;DR version

And finally.. pick the right tools to support the changed workflow, rather than fight the tools and processes we've come up with to date.

We're already almost there at this workflow, but now might be a good time to formalize it before 'head' gets trashed and destabilized (further).

Maybe, just maybe, getting back to what we're really good at and making a top notch, kick-ass, take-no-prisoners technically excellent unix will help our downstream users (PCBSD, pfsense, netapp, juniper, freenas, yahoo, sandvine, etc etc) and ensure a long term niche for us.

FreeBSD-ng (last edited 2011-10-10 17:40:22 by PeterWemm)