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

Julian Elischer julian at freebsd.org
Fri Jun 23 03:58:25 UTC 2017

On 23/6/17 6:36 am, Miroslav Lachman wrote:
> scratch65535 at att.net wrote on 2017/06/23 00:15:
>> [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
>> <linimon at lonesome.com> wrote:
>>> On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65535 at att.net wrote:
>>>> My problem is that my industry experience tells me that reducing
>>>> the frequency of port releases is practically *guaranteed* to be
>>>> a Really Good Thing for everyone.
>>> I remember before we had the quarterly releases, and people on the
>>> mailing lists complained constantly about the ports bits only being
>>> available once per release, or rolling with -head.
>> 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.
> And this is where you are so wrong. Ports tree is never in the state 
> where everything works and has no bugs. (and cannot be, because 
> upstreams have bugs) Even if it compiles and installs it does not 
> mean that it is not broken and nobody needs newer version.
> Just because your needs are different than others doesn't mean 
> others are dilettantes.

The usage of the word dilettante can have negative connotations but he 
is in essential facts correct.

I have spent 30 years on BSD systems in industry, and we almost NEVER 
want the latest and greatest (except at project start time).
What we want is:
   A "recent" starting point for our next project/upgrade to start from
and an ongoing version of that, which will get critical fixes only for 
at LEAST 2 years, probably 5.
The key here is the *_*critical fixes only*_* part.

We do NOT want:
     A new version of perl, python, ssh, shell openssl (*), apache, 
named, etc. etc.
The less changes the better.  Basically if it doesn't have a CVE 
number or it isn't actually completely broken,
then don't upgrade it in that branch.
     We'll fix it ourselves if we need it bad enough (and feed back 
changes if we know it would be taken).

(*) From my experience, the best way to cope with openssl is to have 
everything link with
the system openssl and issue security upgrades to the base OS that 
upgrades that when there is a need.
(this may change, but it's been my experience so far).

The recent starting point doesn't even need to be 100.00% working.
What we will do here is mirror it and from the mirror, put it into our 
own source control branch/tree where we will add our own changes to 
fix/tailor what we need.
We will then keep merging in fixes from upstream. which usually will 
not collide with our private changes/fixes.
 From that we generate our required packages.
 From our perspective, a yearly branch (6 months would be 'ideal' but 
12 would work) that gets only *critical *fixes would be wonderful.
Remember that from the time when a product major release is planned to 
when it comes out is usually 6 to 12 months lead time.
So when it hits the customer's racks,  the packages were usually 
generated somewhere mid-cycle and are already 6 months old.
We will not be replacing them on the customer premises machine until 
they elect to do/purchase an upgrade / patch release.
which may be in a year or two. Certainly for a minor update it is 
rarely less than 6 months.
It'd have to be a heartbleed scale security issue to get customers to 
do an upgrade earlier.

> Miroslav Lachman
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to 
> "freebsd-ports-unsubscribe at freebsd.org"

More information about the freebsd-ports mailing list