Date: Fri, 23 Jun 2017 11:58:14 +0800 From: Julian Elischer <julian@freebsd.org> To: freebsd-ports@freebsd.org Subject: Re: [RFC] Why FreeBSD ports should have branches by OS version Message-ID: <09384577-ed7e-d142-43f3-0a08f5d21056@freebsd.org> In-Reply-To: <594C4663.5080209@quip.cz> References: <CAO%2BPfDeFz1JeSwU3f21Waz3nT2LTSDAvD%2B8MSPRCzgM_0pKGnA@mail.gmail.com> <20170622121856.haikphjpvr6ofxn3@ivaldir.net> <dahnkctsm1elbaqlarl8b9euouaplqk2tv@4ax.com> <20170622141644.yadxdubynuhzygcy@ivaldir.net> <4jrnkcpurfmojfdnglqg5f97sohcuv56sv@4ax.com> <20170622211126.GA6878@lonesome.com> <n8eokc5fafda8gedtvbhh7i0qdk83gur5q@4ax.com> <594C4663.5080209@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23/6/17 6:36 am, Miroslav Lachman wrote:
> scratch65535@att.net wrote on 2017/06/23 00:15:
>> [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
>> <linimon@lonesome.com> wrote:
>>
>>> On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65535@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@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to
> "freebsd-ports-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?09384577-ed7e-d142-43f3-0a08f5d21056>