Solved Question for developers of FBSD that daily drive FBSD as Desktop/Workstation.

BaronBS

BaronBS

I heard from multiple sources (both about FBSD and OBSD) that if I want develop for FBSD (both base and userland) I need to do it in CURRENT.
Fist question round: is this true? if so, Why?
Second question round: how do you go about? RELEASE on metal and CURRENT on VM's/Jails or CURRENT directly on metal? and why?

EDIT: Change title to narrow the scope, because if the dev don't daily drive FBSD it is kind of expected that they will virtualize it anyway.
 
BaronBS said:
I heard from multiple sources (both about FBSD and OBSD) that if I want develop for FBSD (both base and userland) I need to do it in CURRENT.
Fist question round: is this true? if so, Why?
Click to expand...

As typical for most software projects, there is a development branch (CURRENT) where all the new implementations go in before they are broadly tested and mature enough to become part of a RELEASE. Some features and bugfixes are backported to the stable / release branches, but there's no official procedure the other way round.
So you're free to start development on any branch you like, but to contribute you are expected to base your changes on the CURRENT source.

BaronBS said:
Second question round: how do you go about? RELEASE on metal and CURRENT on VM's/Jails or CURRENT directly on metal? and why?
Click to expand...

I'm only an occasional src dev, I run RELEASE on my workstation and CURRENT as a VM / dual boot option on a second SSD. This way I can quickly compile and test patches in the VM, while doing other work on a stable desktop. If I test hardware / drivers that are not available in the VM, I reboot into CURRENT for that.

I think most serious src devs run CURRENT though, to catch more real-world bugs.
 
Isn't that just limiting yourself? Why not test your code in CURRENT after developing it in RELEASE? I mean, if version differences in target FreeBSD systems are significant to your code, you know what you're doing anyway.
 
MG said:
Isn't that just limiting yourself? Why not test your code in CURRENT after developing it in RELEASE? I mean, if version differences in target FreeBSD systems are significant to your code, you know what you're doing anyway.
Click to expand...

Sure, you can do that, on your own, but FreeBSD is a collaboration effort. It's certainly preferable to have a testing ground for new stuff, and to keep it separate from releases for stability reasons. Thus the natural flow of changes is from testing ground (CURRENT) to consolidated changes (RELEASE).
Also, many newly developed features depend on other not yet released features and changes.
 
My opinion, this is not a problem unique to FreeBSD, but rather pretty much all software, even proprietary.

A branch represents "latest and greatest/CURRENT/main/master". Usually allowed a lot more flux and unintentional breakage. Users are expected to kick and scream and curse when it happens but be able to recover their system without much help. I think all versions of Windows fit here.

"maintainence" branches: roughly RELEASE in FreeBSD, LTS in Ubuntu. Security fixes, critical isolated bug fixes. Maybe selective backport of new features.

Now the question becomes:
New feature, should this be back ported? Yes or no, if yes redo on the RELEASE branch.
Security fix, bug fix in CURRENT? Process is "does this exist in RELEASE branches, if so MFC/modify as needed"

Force developers to "eat their own garbage" by running daily driver under CURRENT and bugs tend to get created and fixed faster, but sometimes a lot of time is spent recovering a system which impedes things. An answer to this is 2 systems, one running STABLE/RELEASE, the other running CURRENT.

So given all that, I'd try to run 2 systems and see if I can setup some automated tests against CURRENT. Real hardware is usually better than a VM.
 
BaronBS said:
I heard from multiple sources (both about FBSD and OBSD) that if I want develop for FBSD (both base and userland) I need to do it in CURRENT.
Fist question round: is this true? if so, Why?
Click to expand...

Absolutely not. 99+ % of improvements can be done in any current branch or release and trivially ported to -current for commit.

Since you don't have a commit bit at first anyway that is just fine.
 
You must log in or register to reply here.
Back
Top