Date: Wed, 13 Jun 2012 03:08:12 -0400 From: grarpamp <grarpamp@gmail.com> To: freebsd-questions@freebsd.org Subject: Many open branches = excess FreeBSD project work? Message-ID: <CAD2Ti2-xUkB0vBdUN22obTEdBaaRx%2Bpm4PJLx0euzFsx3eJJnw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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]:
- G HEAD
- G RELENG_9
- S RELENG_9_0
- G RELENG_8
- S RELENG_8_3
- S RELENG_8_2
- S RELENG_8_1
- G RELENG_7
- S RELENG_7_4
Woah!?!?
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
branches...
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):
https://www.youtube.com/watch?v=i7pkyDUX5uM
[1] http://www.freebsd.org/releng/index.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD2Ti2-xUkB0vBdUN22obTEdBaaRx%2Bpm4PJLx0euzFsx3eJJnw>