Question About Tracking the Stable Branch

Freddie Cash fjwcash at
Tue Aug 28 21:03:35 UTC 2012

On Tue, Aug 28, 2012 at 1:31 PM, Jamie Paul Griffin <jamie at> wrote:
> I am following 9 Stable. I have read the handbook information and I am now subscribed to this list and the svn-src-stable-9@ list.
> Even after reading the handbook, what i'm not clear about is this:
> I see individual commits being submitted to the source tree; do I:
>         - patch and update each individual commit, or;
>         - rebuild world say once every couple of days or even each day to incorporate the changes, and;
>         - does the kernel need to be rebuilt and reinstalled each time if using the first option. Obviously I would have to if rebuilding world (the second option).

Personally, I don't update -STABLE boxes unless a specific change
that's useful for my setups comes through.  And then I'll usually wait
1-2 days after the specific commit hits the tree in case there's a
last-minute fix to that commit.

If there's nothing I want to test, or that I need, though, I don't update.

So, it all depends on your needs:
  - are you tracking -STABLE to do development?
  - are you tracking -STABLE to get updated drivers?
  - are you tracking -STABLE to get specific functionality?
  - are you tracking -STABLE to help with bug finding/fixing?
  - etc ...

What your needs are will dictate how often you update the source tree,
rebuild the world, and run with the latest bits.

> Am I right in thinking that it also depends on the type of change; i.e. if the change is to a kernel and/or a kernel module then clearly I need to rebuild the kernel. But, then would I need to rebuild the userland as well?

Most commit logs will include information on whether it's kernel-only,
userland-only, 1-module only, kernel+userland, multiple modules, etc.

Depending on the speed of your machine, you can do a full buildworld
cycle for every update.  Or limit it to just the kernel/userland
component that's updated.

Freddie Cash
fjwcash at

More information about the freebsd-stable mailing list