Many open branches = excess FreeBSD project work?

grarpamp grarpamp at
Wed Jun 13 07:08:17 UTC 2012

We talk about release dates and always slippage and effect on
downstream in other thread. But maybe some causes and even just
related efficiency thing is:

FreeBSD officially maintaining right now [1]:
- S RELENG_9_0
- S RELENG_8_3
- S RELENG_8_2
- S RELENG_8_1
- S RELENG_7_4

Seem a lot of [G]eneral dev and [S]ecurity branches open at once.
It seem crazy, and much extra work for whole FreeBSD project.
Maybe some ways out there to reduce number of open trees/work?
And enhance quality of releases or something in result.

Suggest maybe making just two rolling RELENG (features, stable).
Features be good for adopters and fine polishing post dev teams.
Stable be amazing good production quality all downstream want.
Then short live security/bug (only maintain till next from branch)
releases from both (these be the formal releases).
Focus be on quality level and first row left to right movement
(timing) of feature sets. Second row past Xs1 be just closed snaps
in time.

HEAD -> Features ----------> Stable
     +- Fs1 x Fs2 x Fs3   +- Ss1 x Ss2 x Ss3

Similar to: Do a horizontal collapse two below rows into formal
2.2.x, 4.x, 8.x = good (stable)
other branch.x = intermediate, not maintain worthy (features)

Today FreeBSD think it have to maintain nine trains (aka: rly, wtf)?
I say with some focus tuning tomorrow it does not :)

And just document another project ways (not make any imply from it):


More information about the freebsd-questions mailing list