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

Julian Elischer julian at freebsd.org
Fri Jun 23 17:24:15 UTC 2017

On 23/6/17 11:47 pm, Grzegorz Junka wrote:
> On 23/06/2017 03:58, Julian Elischer wrote:
>> 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.
> Can't you just create the branch yourself? It's open source. You 
> just clone it and can keep it in Github for free. Then you can apply 
> security patches to just the applications you need yourself. If it's 
> too difficult you can hire people to apply just specific patches. 
> With Github pull requests it's deadly easy. I am sure that if you 
> asked maintainers to do the patching for a financial incentive they 
> would mind doing it.
I actually explained it..  We do not have the people who understand 
all those ports.
if there is a port hat gets a fix, one assumes there is a maintainer 
who at least understands that port a bit.
I would feel more comfortable if they made the fix.
Having said that I do think tat we do need to pony up some cash at 
some stage.. and many others should too
if we want to have something like this. I've said this elsewhere.

> Grzegorz
> _______________________________________________
> 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