[RFC] Why FreeBSD ports should have branches by OS version
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
>>>>>> 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.
> freebsd-ports at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-ports-unsubscribe at freebsd.org"
More information about the freebsd-ports