[RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 10:39 am, Kurt Jaeger wrote:
> Hi!
>
>> Mark, I can only suppose that those complainers are dilettantes
>> of some sort who believe that having The Latest-And-Greatest Bits
>> is a social-status enhancer.  **Nobody** with real work to do
>> ever willingly fools away time "fixing" what isn't broken.
> There's a blog post from one of the folks that explains the
> idea behind that 'fast update' mode of operations, and yes,
> he's doing real work.
>
> http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/
>
That is ONE kind of installation.

It only works if you are talking about a software module that is 
either dynamically delivered (think web apps that are downloaded every 
time they are run) or at lear often redelivered. (say, a personal 
system that gets automatic upgrades, a-la slack on OS-X (they seem to 
have  anew version every week or two)
It DOES NOT WORK when th most you can upgrade a customer system is 
once a year or once every two years.

That kind of installation basically "follows head". It doesn't need 
ANY branches. So quarterly branches are of no use to them either.
They are a minority of all commercial users, and a completely non 
existent part of appliance manufacturers,
(because you can't do it that way unless you only have 2 customers (*)).

  * and even then, the customers may only allow you to upgrade every 
so often. For example Bank of America only allow their FreeBSD 
machines to be upgraded after a several month testing and burn-in 
period on a parallel test system with real data and dummy users, and 
that can obviously only happen on a yearly scale as it costs a lot to 
do. (ask Devin about the details..it's been a while since I worked on 
their stuff but I know it's still similar).

To be useful any branch must:
1/ not make unneeded changes, but DO include all/most CRITICAL changes.
2/ stay around and be buildable for at least 3 years, preferably 5.

Note that a company can take care of point 2 themselves to some extent 
by mirroring etc.
but they probably don't have the expertise to handle all if the 
critical (security) patches part of the picture.

I will add that such users would help their own case by fixing such 
issues and feeding the changes back to their branches upstream,
thus helping maintain the branch. Maybe we could have a system of 
"corporate sponsors" for these branches.